4 ms·

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 p

by pc 18y ago

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.

natrius 18y ago
That's better.
apgwoz 18y ago
I'm a bit confused here. If you were to store salted passwords when you create an account: salt = randomstring(4) hashed_pw = salt + ':' + sha1(salt + password) store(hashed_pw, login_name) How do you then verify this? In other words, how do you send the user the salt and the nonce if you don't know who the user is ahead of time?
- Hexstream 18y ago
  Here's how I understand it: 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.
  - tptacek 18y ago
    This is going to make me sound like even more of an asshole, but I'm going to say it anyways because it is true: if you have to explain to yourself what a "salt" is, or you can't spell "nonce", you shouldn't be designing security systems. That doesn't mean your app needs to be insecure; it just means you should be using someone else's authentication system to do it.
    - jncraton 18y ago
      This is hacker news. I think that we are all here to learn. We all have different levels of expertise as well as areas of interest. I'm personally not working a full time coding job yet because I'm still in school and I still have quite a bit that I want to learn just hacking around on my own smaller projects. 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.
      - thaumaturgy 18y ago
        | ...only means that he shouldn't be designing security systems right now. That is almost letter-for-letter what Thomas said.
    - Hexstream 18y ago
      You really need to calm the fuck down. "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.
- newt0311 18y ago
  Here is how it generally works. This method provides a salt along with a nonce. In general, only the actual user knows the password. 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.
  - tptacek 18y ago
    You're not thinking this through. 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.
    - cperciva 18y ago
      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. 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?
- soundsop 18y ago
  I didn't get this either. The page http://pajhome.org.uk/crypt/md5/auth.html http://pajhome.org.uk/crypt/md5/auth.html is a good explanation. 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.

by pc 18y ago

natrius 18y ago

That's better.

apgwoz 18y ago

I'm a bit confused here. If you were to store salted passwords when you create an account: salt = randomstring(4) hashed_pw = salt + ':' + sha1(salt + password) store(hashed_pw, login_name) How do you then verify this? In other words, how do you send the user the salt and the nonce if you don't know who the user is ahead of time?

Hexstream 18y ago
Here's how I understand it: 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.
- tptacek 18y ago
  This is going to make me sound like even more of an asshole, but I'm going to say it anyways because it is true: if you have to explain to yourself what a "salt" is, or you can't spell "nonce", you shouldn't be designing security systems. That doesn't mean your app needs to be insecure; it just means you should be using someone else's authentication system to do it.
  - jncraton 18y ago
    This is hacker news. I think that we are all here to learn. We all have different levels of expertise as well as areas of interest. I'm personally not working a full time coding job yet because I'm still in school and I still have quite a bit that I want to learn just hacking around on my own smaller projects. 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.
    - thaumaturgy 18y ago
      | ...only means that he shouldn't be designing security systems right now. That is almost letter-for-letter what Thomas said.
  - Hexstream 18y ago
    You really need to calm the fuck down. "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.
newt0311 18y ago
Here is how it generally works. This method provides a salt along with a nonce. In general, only the actual user knows the password. 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.
- tptacek 18y ago
  You're not thinking this through. 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.
  - cperciva 18y ago
    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. 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?
soundsop 18y ago
I didn't get this either. The page http://pajhome.org.uk/crypt/md5/auth.html http://pajhome.org.uk/crypt/md5/auth.html is a good explanation. 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.