Page 1 of 1

a couple of security related questions

Posted: Thu Dec 20, 2007 12:27 am
by s.dot
1) Are images as easily sniffed (and converted into viewable data) by the bad guys as POST data?

2) I'm using a sort of challenge response system, except without the challenge. I'm allowing people to password protect a news post without registering or having an account. I use the SHA256 library to hash their password before being sent off for processing by filling a hidden form field with this hash and emptying the password box before submit. This of course requires javascript to be enabled, and if it's not, I will deny them the ability to post unless they have javascript on, for now. I know this is illegal in some locales.. is it legal in the US? I will work on an SSL implementation at some point in the future.

3) If I plainly expose my salting scheme in the javascript, does this make brute force easier on would be attackers? If so, how can I get around this, when I'm using javascript to do the hashing?

4) Say someone were to brute-force, does tokenizing (ie, making a token, storing it in a database, and checking it on submit) my form GUARANTEE that the form submission came from this web site?


This is not how I would normally do things, but I'm working with a client that INSISTS on doing it this way (at least it's nice to finally have a client who knows what he's talking about :P). I'm just trying to make sure I give him as secure of an application as I can, the way he wants it.

Posted: Thu Dec 20, 2007 5:31 am
by Maugrim_The_Reaper
I don't get it really. C/R solves the problem of man-in-the-middle attacks where someone reading network traffic can replay the password submission. Here, you can protect the initial password, but what about subsequent attempts? You then have two options:

1. User submits password in plain text (middle-man intercepts and steals)
2. User submits password, javascript converts to SHA256 (middle-man intercepts, laughs at gynmastics, and steals)

The only reasonable protection in all this is preventing the replay. Every single transmission of a password or password fingerprint should not be capable of being replayed. This is where C/R comes into play since the transmitted data is never the same twice - the challange you send salts the returning data so it becomes unpredictable. A middle-man can gather 1000 data groups and still not have a clue how to reverse engineer anything, since each challenge is unique and highly unlikely to be reused any time soon.

The system you describe breaks down at that level - the javascript probably has the salting system (middle-man can figure it out presumably), the transactions follow a regular and predictable pattern as a result, which means they are probably replayable.
4) Say someone were to brute-force, does tokenizing (ie, making a token, storing it in a database, and checking it on submit) my form GUARANTEE that the form submission came from this web site?
No. A bot would request the form, parse for the token, append it to the outgoing request on the same session using whatever token return system is required, and continue on merrily. It does help by requiring the bot be more complex to handle such a measure.

Posted: Thu Dec 20, 2007 7:56 am
by Mordred
Also, extensive anti-brute-force measures would require a captcha (which is really a different type of C/R token, only it's - supposedly - only readable by humans) and a logging facility that would raise flags on high numbers of unsuccessful password attempts.

Posted: Fri Dec 21, 2007 1:07 pm
by Chalks
Maugrim_The_Reaper wrote:C/R solves the problem...
What is C/R?

Posted: Fri Dec 21, 2007 1:46 pm
by jmut
Chalks wrote:
Maugrim_The_Reaper wrote:C/R solves the problem...
What is C/R?
challenge/response

Posted: Fri Dec 21, 2007 4:23 pm
by Maugrim_The_Reaper
There's a tutorial here:
viewtopic.php?t=38810

Posted: Fri Dec 21, 2007 4:29 pm
by s.dot
Maugrim_The_Reaper wrote:2. User submits password, javascript converts to SHA256 (middle-man intercepts, laughs at gynmastics, and steals)
How does the middle-man steal the sha256 password? Sure he has a 64 character string.. but it can't be reasonably reverse engineered or brute-forced.

Posted: Fri Dec 21, 2007 4:31 pm
by s.dot
Oh, and what about my question of image data being as easily readable/sniffable as post data?

Posted: Fri Dec 21, 2007 5:07 pm
by feyd
Image data can be sniffed in the same manner as they are transported in the same medium as pages.