Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
I agree on your comment about the stupidity of most script kiddies. OTOH, if I get my hands onto your database, I am pretty - well - not a script kiddy anymore (OR your admins are utterly stupid - yes, like this. The SQL Server dba password is empty thing is on this level, and script kiddies are not too likely to exploit the newest vulnerability - this is normally left to hackers knowing their stuff). Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -Original Message- From: Craft, Steve [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 4:45 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes What I stated in my email was a simple way to provide some advantage of a true salt along with some advantage of simple-to-maintain code. Nothing is completely destroyed; the net effect of what I mentioned likely cuts out 90% of the bad guys out there because I believe 90% of the script kiddies out there can't modify the hack-scripts they run. Since adding real entropy to a salt entails some real work (where do the entropy bytes come from, where are the salt values kept, etc), I was suggesting a way to get by some of that. I don't recall stating anywhere in my message that all you need to do is this, my way is perfect. Congratulations. You have misunderstood and twisted my words. Now it's your turn to post your understanding of the maths involved and show me how to work with salt. If I wanted to eat flame, I would have stayed with Perl back in '98. If anyone else has read this far, there is a very good article that discusses randomness/entropy in one of the last 3 issues of WDJ (sorry but I forget which one). Congratulations. You have propably managed to completly destroy the advantage of salt in your usage. Using a derived salt value means, at least to my understanding of the maths involved, that you have just KILLED the effect. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -Original Message- From: Craft, Steve [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 7:08 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes [snip] You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
like that was made, and in fact his salting approach does make a dictionary attack a fair bit more difficult, so it sound to me like a very decent scheme, and he should have a greater sense of security by using that scheme. I could go on about salting forever it would seem, so we'll just end it here. Hopefully this has cleared up a few things, or at least been somewhat informative for at least a few on this list. Jordan Frank eBusiness Applications www.ebusinessapplications.ca [EMAIL PROTECTED] PS: Can we please try to have even just one discussion about security without using the term script kiddy. It's a stupid term, generally used to belittle a group of people who really have nothing to do with anything related to this discussion. Plus, I think it's really silly to call anyone a script kiddy when you're in the security profession. One day, inevitably, one of these people you called a script kiddy is going to break into one of your client's system, or one of your systems. How are you going to explain to either your employer or your client that someone whom you yourself has labeled a complete idiot has outsmarted you. Better just to keep your mouth shut in the first place. Just my opinion though. - Original Message - From: Thomas Tomiczek [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 10, 2003 3:57 AM Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes IMHO there is not something like a bit harsh in regards of security. I accept the security against the script kiddy argument, but for anything else, salt should be white noise. The (false) assumption that you have a secure encryption algorythm, where in reality you do not have one, is the worst thing that you can actually have - much worse than not having an algorythm at all, because then you KNOW that you are unprotected. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -Original Message- From: Andrew Hopper [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 8:57 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes Gosh, that's being a bit harsh. He already admitted that it's not as secure as a random salt. While it's true that using a derived salt is not as secure as a random salt, it is definitely more secure than using no salt at all. With this approach, it is required that A) the black hat know your salt algorithm (which, unfortunately, is not terribly complicated in this case but is still better than nothing) and B) the black hat generate a hashed dictionary using the now-known salt and a non-hashed dictionary. Again, this approach is nowhere near as secure as when using a random salt, but he is correct in stating that it will slow down, if not keep out, script kiddies. -Andy Hopper - Original Message - From: Thomas Tomiczek [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 3:08 AM Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes Congratulations. You have propably managed to completly destroy the advantage of salt in your usage. Using a derived salt value means, at least to my understanding of the maths involved, that you have just KILLED the effect. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -Original Message- From: Craft, Steve [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 7:08 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes In the case of storing username/password in a database table, I just use a salt of the username backwards and append that to the password before it gets encrypted and written to the password column. In normal app usage, the username is looked up and then the backwards username is appended to the password and that hash is compared to the password column. That's not the most earth-shattering way of doing things, but it should slow down any script-kiddie that gets the password file; he will have to append the username to every password try on every different table row. It also makes the salt different for each user, but is easier to maintain than a random number (or even a well-known hard-coded number) for each one. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
Jordan, while agreeing on everything, I consider the term script kiddie to be very usefull. It is usefull to decribe a certain type of attack: basically an automated attack by an uneducated user. It can be characterised by using a preprogrammed tool (the script) without any knowledge of what is actually going on. Script kiddies are normally attacking on well known exploits, and can normally be kept off guard by basically changing a smal implementation detail and/or having competent administrators. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
IMHO there is not something like a bit harsh in regards of security. I accept the security against the script kiddy argument, but for anything else, salt should be white noise. The (false) assumption that you have a secure encryption algorythm, where in reality you do not have one, is the worst thing that you can actually have - much worse than not having an algorythm at all, because then you KNOW that you are unprotected. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -Original Message- From: Andrew Hopper [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 8:57 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes Gosh, that's being a bit harsh. He already admitted that it's not as secure as a random salt. While it's true that using a derived salt is not as secure as a random salt, it is definitely more secure than using no salt at all. With this approach, it is required that A) the black hat know your salt algorithm (which, unfortunately, is not terribly complicated in this case but is still better than nothing) and B) the black hat generate a hashed dictionary using the now-known salt and a non-hashed dictionary. Again, this approach is nowhere near as secure as when using a random salt, but he is correct in stating that it will slow down, if not keep out, script kiddies. -Andy Hopper - Original Message - From: Thomas Tomiczek [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 3:08 AM Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes Congratulations. You have propably managed to completly destroy the advantage of salt in your usage. Using a derived salt value means, at least to my understanding of the maths involved, that you have just KILLED the effect. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -Original Message- From: Craft, Steve [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 7:08 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes In the case of storing username/password in a database table, I just use a salt of the username backwards and append that to the password before it gets encrypted and written to the password column. In normal app usage, the username is looked up and then the backwards username is appended to the password and that hash is compared to the password column. That's not the most earth-shattering way of doing things, but it should slow down any script-kiddie that gets the password file; he will have to append the username to every password try on every different table row. It also makes the salt different for each user, but is easier to maintain than a random number (or even a well-known hard-coded number) for each one. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
What I stated in my email was a simple way to provide some advantage of a true salt along with some advantage of simple-to-maintain code. Nothing is completely destroyed; the net effect of what I mentioned likely cuts out 90% of the bad guys out there because I believe 90% of the script kiddies out there can't modify the hack-scripts they run. Since adding real entropy to a salt entails some real work (where do the entropy bytes come from, where are the salt values kept, etc), I was suggesting a way to get by some of that. I don't recall stating anywhere in my message that all you need to do is this, my way is perfect. Congratulations. You have misunderstood and twisted my words. Now it's your turn to post your understanding of the maths involved and show me how to work with salt. If I wanted to eat flame, I would have stayed with Perl back in '98. If anyone else has read this far, there is a very good article that discusses randomness/entropy in one of the last 3 issues of WDJ (sorry but I forget which one). Congratulations. You have propably managed to completly destroy the advantage of salt in your usage. Using a derived salt value means, at least to my understanding of the maths involved, that you have just KILLED the effect. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -Original Message- From: Craft, Steve [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 7:08 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes [snip] You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
Gosh, that's being a bit harsh. He already admitted that it's not as secure as a random salt. While it's true that using a derived salt is not as secure as a random salt, it is definitely more secure than using no salt at all. With this approach, it is required that A) the black hat know your salt algorithm (which, unfortunately, is not terribly complicated in this case but is still better than nothing) and B) the black hat generate a hashed dictionary using the now-known salt and a non-hashed dictionary. Again, this approach is nowhere near as secure as when using a random salt, but he is correct in stating that it will slow down, if not keep out, script kiddies. -Andy Hopper - Original Message - From: Thomas Tomiczek [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 3:08 AM Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes Congratulations. You have propably managed to completly destroy the advantage of salt in your usage. Using a derived salt value means, at least to my understanding of the maths involved, that you have just KILLED the effect. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -Original Message- From: Craft, Steve [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 7:08 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes In the case of storing username/password in a database table, I just use a salt of the username backwards and append that to the password before it gets encrypted and written to the password column. In normal app usage, the username is looked up and then the backwards username is appended to the password and that hash is compared to the password column. That's not the most earth-shattering way of doing things, but it should slow down any script-kiddie that gets the password file; he will have to append the username to every password try on every different table row. It also makes the salt different for each user, but is easier to maintain than a random number (or even a well-known hard-coded number) for each one. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
In the case of storing username/password in a database table, I just use a salt of the username backwards and append that to the password before it gets encrypted and written to the password column. In normal app usage, the username is looked up and then the backwards username is appended to the password and that hash is compared to the password column. That's not the most earth-shattering way of doing things, but it should slow down any script-kiddie that gets the password file; he will have to append the username to every password try on every different table row. It also makes the salt different for each user, but is easier to maintain than a random number (or even a well-known hard-coded number) for each one. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
Original question was: Can someone help me understand the usage of a salt in PasswordDeriveBytes? My understanding of salts has definitely crystalized (pun mostly not intended). This thread has been very helpful thanks to all who contributed. Cheers, Ed -Original Message- From: Craig Andera [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 10:47 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes snip/ But the question was asking about salts, it wasn't asking for a recommendation on the entire authentication infrastructure. Even if it was, there was not enough information given about the application for anyone to just say use a public key cryptosystem. Sounds like we were in violent agreement the whole time. At any rate, I'm curious if we ever did answer the orinal question. Original poster? You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
That's not the most earth-shattering way of doing things, but it should slow down any script-kiddie that gets the password file; he will have to append the username to every password try on every different table row. It also makes the salt different for each user, but is easier to maintain than a random number (or even a well-known hard-coded number) for each one. I use both: the password plus the username plus some fixed random salt from the config file. It's trivial to pull something out of the config file with ConfigurationSettings.AppSettings. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
The more I think about it, the more I come to realize that the salt should never leave the server. It adds nothing, and takes away something. It's whole purpose is to make it somewhat harder to perform dictionary attacks against the password database. Transmitting it on the wire is just going to make it that much easier to assault the password file. Craig, Let's revisit your function - f(password + random garbage + timestamp, Bob's public key) Given our definition of nonce and salt what is random garbage? Random garbage = a string of random characters. Ideally, this would be cryptographically securely generated random numbers, since the default random number generator blows. Who generates the random garbage, The client. and when? every time they send a password. Does the random garbage need to be shared, if so, how is this achieved? Nope. On the server side, you decrypt the password + timestamp + garbage and just throw away the garbage. This assumes either a delimiter or a fixed length of garbage. I suggest you check out [1], which is the RFC for PKCS #1. Not only does it outline a standard way of doing this, but you'll need to use this if you want to decrypt the resulting cyphertext with the .NET Crypto APIs. [1] http://www.ietf.org/rfc/rfc2313.txt NB: It's a terrible idea to implement your own protocols! There is a high liklihood that a real cryptanalyst can come along and blow 20 holes in the ideas we're floating here. Unless you have a PhD in number theory, you're better off just using SSL. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
If the salt is considered a secret, then what's it's purpose? It can't be sent to the client (because it's a secret), and it therefore cannot be hashed with the password on the client side. So therefore it can't have been hashed with the password for storage on the server, because that'd be useless. The whole point is that you have to do the exact same operation on both the client side and the server side if you want to communicate over an insecure channel. So you need to have the exact same information on the client and server. The idea is to essentially do H(S+R) where H is a hash function, S is the secret, and R is something random to prevent replay attacks. Anything else you do is just obfuscation, which does not add security. H(S+R) must be done on both the client and the server, and therefore the exact same S and R must be available to both the client and the server. There's really nothing more to discuss with regards to that matter. What I was trying to point out, was that the salting you were suggesting added nothing to the security of the scheme. It only served to make it harder to crack the passwords if the password file is compromised. It does not make it any harder to log in to your system if the password files were compromised, because you end up hashing the exact contents of the password file as part of your scheme. So the attacker doesn't need to know the password. Recovering the plaintext passwords is more difficult though, but how important is that if the plaintext passwords aren't needed to log into the system. As far as encrypting the password goes, it definitely does add an extra layer of protection because the password file on it's own is useless. Sure, if the attacker compromises the entire system and is able to run code on the server, then he can just inject code that will decrypt the password file and print it out. But, it is far more often the case that a password file becomes readable by some human error, either permissions aren't set up properly, it's FTPed or emailed to some other system, or whatever. If this is the case, then my scheme will protect you. Obviously if the server needs to work with the secret, then it's impossible to make that secret 100% secure, but encrypting the password file adds another important layer of security. NTLM, HTTP Digest, these all hash the password with a nonce or challenge. That shouldn't be news to anyone. If the hash algorithm is secure, then this scheme is secure, and that's a pretty well known fact. Salting assists in password storage, as it is mixed in with the password before hashing occurs. Therefore if the salt is not available to the client, then it cannot be mixed in with the password before hashing occurs on the client side, so it is useless. The salt must be known by whomever is doing the hashing, no matter what. Whether you want to call it a secret or not is irrelevant, it's really just being treated as part of the password. Now, if you actually come up with a password based authentication scheme that is impervious to brute-force attacks (or slightly more intelligent brute force attacks, which we'll call dictionary attacks), then that's news. But salting sure as heck isn't the answer. Using a public key cryptosystem may be the answer, but the nightmare of key management should never be underestimated, especially if you want your users to be able to access your system from a web-cafe (for example). Using certificates and whatnot would be a very good idea however, if it's feasible for your application. But the question was asking about salts, it wasn't asking for a recommendation on the entire authentication infrastructure. Even if it was, there was not enough information given about the application for anyone to just say use a public key cryptosystem. Jordan Frank eBusiness Applications www.ebusinessapplications.ca [EMAIL PROTECTED] - Original Message - From: Craig Andera [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 6:59 AM Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes [...] You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
There is a thread in the old DotNet archive that talks about how to protect against replay attacks without using SSL. I believe it has to do with the client requesting a token from the server, then hashing the token with the password and passing that to the sever on a second trip. -Original Message- From: Craig Andera [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 10:08 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes Can someone help me understand the usage of a salt in PasswordDeriveBytes? I think I understand, but I want confirmation. Right now, I create a salt for each user when the user is created. I use PasswordDeriveBytes to create a userkey based on a password and the salt. Then I store the userkey and the salt. Now, I don't want to transmit a password over the wire right? So client side code needs three things to prepare its authentication message. 1) the password from the user, 2) a nonce, and 3) the salt. I have not stored the password because I don't want an attacker to be able to walk off with the password file. I have not stored a simple hashed password because I don't want an attacker to be able to walk off with the password file and use dictionary attacks against it. I have stored a salted hashed password - so the client needs the salt in order to create the user key. Is this right? Should I be allowing anyone to say My user name is joe, what is the salt I should be using?. I've been writing a system for the last month to deal with exactly this problem. I'm not sure I understand you, but if I do, you're missing something pretty fundamental. Assume a user Alice. Assume she's talking to a system called Bob. Assume a malicious attacker Mallory. You say you don't want to send a password over the wire in the clear. This is correct, but the *reason* is that you don't want Mallory to be able to steal it, since that would mean they could authenticate to Bob as Alice. If you have Alice send a hashed password, all Mallory has to do is to steal that and transmit it to Bob with Mallory's fake request. There are generally two approaches to this: 1) Make sure you use SSL or the equivalent between Alice and Bob. In that case, Mallory can't read their traffic. Note that sophisticated attackers might still be able to do something useful with the traffic, but it's better. 2) If you can't encrypt the channel, encrypt the password USING A RANDOMLY SALTED PUBLIC KEY CIPHER. That is, you send f(password + random garbage + timestamp, Bob's public key), where f is something like RSA. Anyone can perform the encryption - the public key is widely known - but only Bob can decrypt the password. Appending random salt means that Mallory can't just dictionary the password. Using a timestamp means that Mallory has to be quick to simply replay the encrypted password. 1 is by far preferable. 2 is still subject to replay attacks, albeit only within a certain timeframe. 2 has the additional problem of requiring Alice and Bob to synchronize their clocks. Note that 2 requires a PUBLIC key algorithm. If you use a symmetric cypher like DES, you have the problem of how to get Alice the shared key securely. Make sense? You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
There is a thread in the old DotNet archive that talks about how to protect against replay attacks without using SSL. I believe it has to do with the client requesting a token from the server, then hashing the token with the password and passing that to the sever on a second trip. I'd be careful of this route: if you do it naively, it's going to be fairly simple to run a dictionary attack against weak passwords. I haven't looked at CHAP, though. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
Hey Craig, Thanks for the reply. I guess I should have been more clear. I agree that channel encryption is important, however, my question is about the security protocol, not about the channel. I guess I'm somewhat confused about two commonly used terms - salt and nonce. What you refer to as random salt I've always thought as a nonce (number used once). To me, the term salt has always represented a randomly generated, but persisted set of bytes that are used to make dictionary attacks impractical. Using my definition of salt, here is my question in a little more detail. Let's say the user creates a password P and the system creates a salt S and hashes the password and the salt creating a userkey K. The system then stores the username U, the userkey K, and the salt S. Then, for authentication: 1. If the client sends username U U 2. The server creates a nonce N with a short TTL and sends it and the salt S N, S 3. The client applies hash h to the user's password P, and the salt using the PasswordDeriveBytes class, and then hashes this with the nonce h(h(P + S), N) 4. If the nonce's TTL has not expired when the client submits its response, the server then uses the same function to verify that h(K, N) Matches whatever the client sent (where K = userkey as defined above). My question is about step 1 and 2. Is this how the salt is supposed to be managed? Cheers, Ed You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
Also see HTTP digest authentication in RFC 2617 [1] which discusses the appropriate security issues and includes a C sample implementation. Unfortunately, you will suffer from dictionary attacks unless you use asymmetric keys or shared secrets but maintaining those is an overhead you might not wish to have. Adrian. [1] http://www.ietf.org/rfc/rfc2617.txt On 06 January 2003 17:21, Craig Andera wrote: There is a thread in the old DotNet archive that talks about how to protect against replay attacks without using SSL. I believe it has to do with the client requesting a token from the server, then hashing the token with the password and passing that to the sever on a second trip. I'd be careful of this route: if you do it naively, it's going to be fairly simple to run a dictionary attack against weak passwords. I haven't looked at CHAP, though. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
Err, I think your protocol is still subject to dictionary attacks
against weak passwords. E.g., I'm Mallory, I intercept
{h(h(P+S), N), S, N}
all of which are sent cleartext, then use a dictionary attack to recover
P by simply permuting P values and computing
h(h(P+S), N)
until he gets a match. Mallory can't precompute this quantity for all
values of N, but users tend to use crappy passwords, and he can most
likely try a few million per second on a fast machine.
I agree with your definition of salt, BTW: it's something we keep around
for a while. A nonce is something we use once.
Schneier, Applied Cryptography: Salt isn't a panacea; increasing the
number of salt bits won't solve everything. Salt only protects against
general dictionary attacks on a password file, not a concerted attack on
a single password. It protects people who have the same password on
multiple machines, but doesn't make poorly chosen passwords any better.
If you are implementing security, I highly suggest reading the first
third of this book, and using the rest as reference.
-Original Message-
From: Pinto, Ed [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 06, 2003 12:50 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
Hey Craig,
Thanks for the reply. I guess I should have been more clear.
I agree that
channel encryption is important, however, my question is
about the security
protocol, not about the channel.
I guess I'm somewhat confused about two commonly used terms - salt and
nonce. What you refer to as random salt I've always
thought as a nonce
(number used once). To me, the term salt has always represented a
randomly generated, but persisted set of bytes that are used to make
dictionary attacks impractical. Using my definition of salt,
here is my
question in a little more detail.
Let's say the user creates a password P and the system
creates a salt S and
hashes the password and the salt creating a userkey K. The
system then
stores the username U, the userkey K, and the salt S. Then, for
authentication:
1. If the client sends username U
U
2. The server creates a nonce N with a short TTL and sends it
and the salt S
N, S
3. The client applies hash h to the user's password P, and
the salt using
the PasswordDeriveBytes class, and then hashes this with the nonce
h(h(P + S), N)
4. If the nonce's TTL has not expired when the client submits
its response,
the server then uses the same function to verify that
h(K, N)
Matches whatever the client sent (where K = userkey as defined above).
My question is about step 1 and 2. Is this how the salt is
supposed to be
managed?
Cheers,
Ed
You can read messages from the Advanced DOTNET archive,
unsubscribe from Advanced DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
On 06 January 2003 17:50, Pinto, Ed wrote: I guess I'm somewhat confused about two commonly used terms - salt and nonce. What you refer to as random salt I've always thought as a nonce (number used once). To me, the term salt has always represented a randomly generated, but persisted set of bytes that are used to make dictionary attacks impractical. Using my definition of salt, here is my question in a little more detail. My impression was that the salt is merely used to ensure that the same password will result in different bytes. For example, if it were not used in /etc/passwd then I would be able to see other people with the same password as me because the data stored in the password file would be identical. The salt value is very likely to be different so the data would be even for the same password. In your example, K+S is equivalent to the /etc/passwd entry so that buys you the fact that you don't need to store the password in the clear. The nonce N handles reducing the replay window. Essentially, then, you're mixing the solution to two problems to arrive at your algorithm. That seems fair. Adrian. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
Thanks Craig, Thanks Adrian.
Craig, Let's revisit your function -
f(password + random garbage + timestamp, Bob's public key)
Given our definition of nonce and salt what is random garbage?
Who generates the random garbage, and when?
Does the random garbage need to be shared, if so, how is this achieved?
Cheers,
Ed
-Original Message-
From: Craig Andera [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 06, 2003 2:44 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
Err, I think your protocol is still subject to dictionary attacks against
weak passwords. E.g., I'm Mallory, I intercept
{h(h(P+S), N), S, N}
all of which are sent cleartext, then use a dictionary attack to recover P
by simply permuting P values and computing
h(h(P+S), N)
until he gets a match. Mallory can't precompute this quantity for all values
of N, but users tend to use crappy passwords, and he can most likely try a
few million per second on a fast machine.
I agree with your definition of salt, BTW: it's something we keep around for
a while. A nonce is something we use once.
Schneier, Applied Cryptography: Salt isn't a panacea; increasing the number
of salt bits won't solve everything. Salt only protects against general
dictionary attacks on a password file, not a concerted attack on a single
password. It protects people who have the same password on multiple
machines, but doesn't make poorly chosen passwords any better.
If you are implementing security, I highly suggest reading the first third
of this book, and using the rest as reference.
-Original Message-
From: Pinto, Ed [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 06, 2003 12:50 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
Hey Craig,
Thanks for the reply. I guess I should have been more clear.
I agree that
channel encryption is important, however, my question is
about the security
protocol, not about the channel.
I guess I'm somewhat confused about two commonly used terms - salt and
nonce. What you refer to as random salt I've always thought as a
nonce (number used once). To me, the term salt has always
represented a randomly generated, but persisted set of bytes that are
used to make dictionary attacks impractical. Using my definition of
salt, here is my
question in a little more detail.
Let's say the user creates a password P and the system
creates a salt S and
hashes the password and the salt creating a userkey K. The
system then
stores the username U, the userkey K, and the salt S. Then, for
authentication:
1. If the client sends username U
U
2. The server creates a nonce N with a short TTL and sends it
and the salt S
N, S
3. The client applies hash h to the user's password P, and
the salt using
the PasswordDeriveBytes class, and then hashes this with the nonce
h(h(P + S), N)
4. If the nonce's TTL has not expired when the client submits
its response,
the server then uses the same function to verify that
h(K, N)
Matches whatever the client sent (where K = userkey as defined above).
My question is about step 1 and 2. Is this how the salt is
supposed to be
managed?
Cheers,
Ed
You can read messages from the Advanced DOTNET archive,
unsubscribe from Advanced DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes
schemes. All opinions stated in this email are my own and do not necessarily reflect those of my employer, or anyone else for that matter. - Original Message - From: Pinto, Ed [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 06, 2003 9:50 AM Subject: Re: [ADVANCED-DOTNET] Salt in PasswordDeriveBytes | Hey Craig, | Thanks for the reply. I guess I should have been more clear. I agree that | channel encryption is important, however, my question is about the security | protocol, not about the channel. | | I guess I'm somewhat confused about two commonly used terms - salt and | nonce. What you refer to as random salt I've always thought as a nonce | (number used once). To me, the term salt has always represented a | randomly generated, but persisted set of bytes that are used to make | dictionary attacks impractical. Using my definition of salt, here is my | question in a little more detail. | | Let's say the user creates a password P and the system creates a salt S and | hashes the password and the salt creating a userkey K. The system then | stores the username U, the userkey K, and the salt S. Then, for | authentication: | | 1. If the client sends username U | U | | 2. The server creates a nonce N with a short TTL and sends it and the salt S | N, S | | 3. The client applies hash h to the user's password P, and the salt using | the PasswordDeriveBytes class, and then hashes this with the nonce | h(h(P + S), N) | | 4. If the nonce's TTL has not expired when the client submits its response, | the server then uses the same function to verify that | h(K, N) | Matches whatever the client sent (where K = userkey as defined above). | | My question is about step 1 and 2. Is this how the salt is supposed to be | managed? | | Cheers, | Ed | | You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or | subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
