No. The server stores salted hashes, and serves the salt and a nonce as part of the login page. The client then submits hash(nonce + hash(salt + pass)).
This protects against both replay and rainbow attacks.
This protects against both replay and rainbow attacks.
salt = randomstring(4)
hashed_pw = salt + ':' + sha1(salt + password)
store(hashed_pw, login_name)
The salt is generated on the server, it's always the same for a given user (and possibly all users). You concatenate this with the password in some way. The utility of this is that if a user's password is mypassword then it will be hashed as, say, mypasswordsalt so someone with a "rainbow table" of all hashes and the corresponding cleartext would normally have quickly known that the hash's cleartext is mypassword but the dictionary will fail to match the hash since there's no entry for mypasswordsalt. This is how rainbow tables are made useless should the attacker get access to the passwords in the database.
I never used the nounce technique and can only make guesses so I'll refrain from trying to explain that part.
"if you have to explain to yourself what a "salt" is, or you can't spell "nonce", you shouldn't be designing security systems."
No, I don't have to explain to myself what a salt is, though my "Here's how I understand it" introduction probably mislead you into thinking that. The only reason I said "Here's how I understand it" is that initially I wanted to explain both what a salt is (a notion I certainly understand because I read about it and implemented it) and what a nonce is (a notion I probably don't understand because I didn't really read about it and didn't implement it).
I know I still have much to learn but at least I know what I don't know with respect to nonces, and I find it pretty lame that you're saying I shouldn't "design security systems" just because I can't spell a word properly for a technique I just admitted I "never used and can only make guesses [about]"
I've been working like crazy for the last 2 years to learn everything about Common Lisp and making websites and you're saying I should give up everything just because I still have things to learn?!
You can't judge someone's skills just by looking at a data point like that. The concepts of closures and macros are now completely automatic and obvious to me but I wouldn't call someone who never heard of it or has just a basic understanding of it "someone who should never program". Of course I'd point it out if they said they had a firm grasp of it while it was obvious that they didn't.
A huge fraction of the security breaks over the past 15 years --- which cost us billions and billions of dollars --- are traceable to the mindset that says that figuring out security is just like figuring out how to scale a database: "you try and try and try until you get it right". Well, no.
I don't have an authentication system to sell you, but someone else does, and you should use it before you try to build one yourself.
The fact that the concept of a salt isn't totally automatic to him or that he misspelled nonce only means that he shouldn't be designing security systems right now. There is a lot that we can all learn, some of us just have farther to go than others.
That is almost letter-for-letter what Thomas said.
Regarding the salt, the page says:
Using a different salt for each user presents an issue: the salt isn't known until the user name is known. For a web application, this would require a two-stage login form - one form asking for the user name and a second asking for the password. Such an arrangement would be quite unfriendly towards users. Fortunately, there is a simple alternative. The salt is generated by concatonating the user name with a "system salt". The system salt is the same for all users on one system.
Start: User registers for a service and submits a username + password.
The password is salted and hashed in the browser and then sent to the server over a secure connection along with other info. like username etc...
Then when somebody wants to so log in: Server sends a random nonce and keeps track of nonce for all requests when the initial login page is sent to the browser.
Then the user enters username + password to the browser. The browser computes hash(nonce + hash(salt(password))) and sends the result to the server along with username info.
The server looks up the password hash associated with the username and compares hash(nonce + stored-hash) vs. the info. sent by the browser. If there is equality, the user is authenticated and interaction proceeds as normal.
Note that only the user actually knows the password. Even the server only has the hash of a salted version of the password. Next, even this salted hash is never sent directly over the network. A decent implementation will randomize the nonce so that packet sniffing attacks don't work.
Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security.
If attackers don't have access to raw traffic, sending over the plaintext password is just fine, because attackers don't have access to raw traffic.
I'm sorry, but security isn't an obstacle course. For evidence, go research what percentage of online bank transactions in Brazil were fraudulent in 2007. There is no clever solution to this problem.
Send passwords over SSL, or don't care about the password you send.
No. It's entirely possible for an attacker to have access to your data (say, because they compromise a system which has been dumping packets for offline analysis) without being able to rewrite packets in transit.
I'm not saying that the suggested mechanism is a good idea, but let's be honest in our security analyses, ok?
Personally, I think you do a grave disservice to developers by dignifying the notion that "passive-only attacks" are a reasonable threat model.
But even if only 0.0001% of attackers are limited to passive-only attacks (and I suspect the actual value is higher -- more like 0.1%) then the suggested mechanism is 0.0001% more secure than transmitting the password in plaintext -- which invalidates your assertion that it "provides no additional security".
I know you're smarter than this, Colin. I think you're being pedantic. Would you advise anyone on this message board any differently than me? I think you already said "no".
There are two parts to giving advice: Helping people with their immediate question, and helping people better understand the field in question so that they won't need your advice the next time. You told people that what they were talking about doing was a bad idea, which I agree with; but the explanation you gave was misleading.
I agree with your recommendation of "don't do that"; but I think it's important for people to understand WHY they shouldn't do that -- and claiming that it's "no more secure" rather than explaining that it's very slightly more secure obfuscates rather than elucidates.
Banks in Brazil routinely issue each customer with a duress PIN to mitigate the situation of a customer being frogmarched to an ATM at gunpoint. This is in addition to ATMs being unavailable in early hours due to the majority transactions being theft at gunpoint.
Initial implementations of the duress PIN displayed an identical withdrawal limit and led to customers being shot. Subsequent implementations provide a reduced limit.
I discovered this after lending a trifling amount to a Brazilian ex-colleague in the UK. He retained his Brazilian bank account and, to repay me, he had calculate the timezone differences for ATM use.