|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
password saltingin the patterns and practices guidelines for securing applications it
recommends hashing passwords and using a salt if storing to a database (i am ok with this bit). however, it also recommends appending the salt to the hashed password for simplified storage and then makes the following statement:- This approach means you do not need to store the salt separately. To verify a password, you extract the salt from the stored combination of the hash and salt value and then recomputed the hash using the salt value and the plaintext password value obtained from the user. my question is, how exactly do you extract the salt from the stored combination? is it really as simple as knowing in advance that the salt was x characters long so you can do an easy substring when extracting? or is there another method? It really is that simple, but you would tend to do it in bytes instead of
characters. The hash would be the first X bytes and the salt would be the remaining bytes, or vice versa. If you store the value in the database as a string, make sure you convert to Base64. Then, after you read it back out, convert back to byte[] with Base64 again and then just grab the relevant parts of the byte array. Joe K. -- Show quoteHide quoteJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "Dan" <D**@discussions.microsoft.com> wrote in message news:1456564F-FF25-4D1A-B263-5E2A17A10D4C@microsoft.com... > in the patterns and practices guidelines for securing applications it > recommends hashing passwords and using a salt if storing to a database (i > am > ok with this bit). however, it also recommends appending the salt to the > hashed password for simplified storage and then makes the following > statement:- > > This approach means you do not need to store the salt separately. To > verify > a password, you extract the salt from the stored combination of the hash > and > salt value and then recomputed the hash using the salt value and the > plaintext password value obtained from the user. > > my question is, how exactly do you extract the salt from the stored > combination? is it really as simple as knowing in advance that the salt > was x > characters long so you can do an easy substring when extracting? or is > there > another method? But if the source isn't secure what is the point of doing this? And if the
source is secure, then there is no pointing is storing the salt this way in the first place. Rob. Show quoteHide quote "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote in message news:OVEeLjwuGHA.5056@TK2MSFTNGP06.phx.gbl... > It really is that simple, but you would tend to do it in bytes instead of > characters. The hash would be the first X bytes and the salt would be the > remaining bytes, or vice versa. > > If you store the value in the database as a string, make sure you convert > to Base64. Then, after you read it back out, convert back to byte[] with > Base64 again and then just grab the relevant parts of the byte array. > > Joe K. > > -- > Joe Kaplan-MS MVP Directory Services Programming > Co-author of "The .NET Developer's Guide to Directory Services > Programming" > http://www.directoryprogramming.net > -- > "Dan" <D**@discussions.microsoft.com> wrote in message > news:1456564F-FF25-4D1A-B263-5E2A17A10D4C@microsoft.com... >> in the patterns and practices guidelines for securing applications it >> recommends hashing passwords and using a salt if storing to a database (i >> am >> ok with this bit). however, it also recommends appending the salt to the >> hashed password for simplified storage and then makes the following >> statement:- >> >> This approach means you do not need to store the salt separately. To >> verify >> a password, you extract the salt from the stored combination of the hash >> and >> salt value and then recomputed the hash using the salt value and the >> plaintext password value obtained from the user. >> >> my question is, how exactly do you extract the salt from the stored >> combination? is it really as simple as knowing in advance that the salt >> was x >> characters long so you can do an easy substring when extracting? or is >> there >> another method? > > I'm not sure what you mean here, Rob. Can you explain?
The general recommendation is to salt your hashes, as that makes them very difficult to crack brute force if they are somehow stolen. If you are going to salt your hashes, you have to have the salt available when you go to compare the hashed value. Where would you recommend storing the salt otherwise? The other standard way is in a second column in the table. Joe K. -- Show quoteHide quoteJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "Rob R. Ainscough" <roba***@pacbell.net> wrote in message news:OZzM3XzuGHA.4688@TK2MSFTNGP06.phx.gbl... > But if the source isn't secure what is the point of doing this? And if > the source is secure, then there is no pointing is storing the salt this > way in the first place. > > Rob. > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote > in message news:OVEeLjwuGHA.5056@TK2MSFTNGP06.phx.gbl... >> It really is that simple, but you would tend to do it in bytes instead of >> characters. The hash would be the first X bytes and the salt would be >> the remaining bytes, or vice versa. >> >> If you store the value in the database as a string, make sure you convert >> to Base64. Then, after you read it back out, convert back to byte[] with >> Base64 again and then just grab the relevant parts of the byte array. >> >> Joe K. >> >> -- >> Joe Kaplan-MS MVP Directory Services Programming >> Co-author of "The .NET Developer's Guide to Directory Services >> Programming" >> http://www.directoryprogramming.net >> -- >> "Dan" <D**@discussions.microsoft.com> wrote in message >> news:1456564F-FF25-4D1A-B263-5E2A17A10D4C@microsoft.com... >>> in the patterns and practices guidelines for securing applications it >>> recommends hashing passwords and using a salt if storing to a database >>> (i am >>> ok with this bit). however, it also recommends appending the salt to the >>> hashed password for simplified storage and then makes the following >>> statement:- >>> >>> This approach means you do not need to store the salt separately. To >>> verify >>> a password, you extract the salt from the stored combination of the hash >>> and >>> salt value and then recomputed the hash using the salt value and the >>> plaintext password value obtained from the user. >>> >>> my question is, how exactly do you extract the salt from the stored >>> combination? is it really as simple as knowing in advance that the salt >>> was x >>> characters long so you can do an easy substring when extracting? or is >>> there >>> another method? >> >> > > If you have the salt and the hash, the salt does not make attacking your
password much harder (only a tinny bit). Different salt per user only forces one to crack *each password separately - even if they are the same clear text password. But it does not slow the algo down much if I have the salt and can infer the algo used (i.e. hash (pw + salt) or hash(salt+pw)). In most cases, the attacker does not need or care about all passwords, only 1. And he can run the algo all week until he finds it (doing millions of iterations per minute using many dictionaries and combinations, etc). So the salt does not really help if it is in the clear and with the user's hash record. Additional protection would be to store the salt encrypted if possible. Then I can't really do a brute force attack. One could try, but good luck with that on a crypto random 16 byte salt or greater. -- Show quoteHide quoteWilliam Stacey [MVP] "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote in message news:e9Txl9zuGHA.5084@TK2MSFTNGP04.phx.gbl... | I'm not sure what you mean here, Rob. Can you explain? | | The general recommendation is to salt your hashes, as that makes them very | difficult to crack brute force if they are somehow stolen. If you are going | to salt your hashes, you have to have the salt available when you go to | compare the hashed value. Where would you recommend storing the salt | otherwise? The other standard way is in a second column in the table. | | Joe K. | | -- | Joe Kaplan-MS MVP Directory Services Programming | Co-author of "The .NET Developer's Guide to Directory Services Programming" | http://www.directoryprogramming.net | -- | "Rob R. Ainscough" <roba***@pacbell.net> wrote in message | news:OZzM3XzuGHA.4688@TK2MSFTNGP06.phx.gbl... | > But if the source isn't secure what is the point of doing this? And if | > the source is secure, then there is no pointing is storing the salt this | > way in the first place. | > | > Rob. | > | > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote | > in message news:OVEeLjwuGHA.5056@TK2MSFTNGP06.phx.gbl... | >> It really is that simple, but you would tend to do it in bytes instead of | >> characters. The hash would be the first X bytes and the salt would be | >> the remaining bytes, or vice versa. | >> | >> If you store the value in the database as a string, make sure you convert | >> to Base64. Then, after you read it back out, convert back to byte[] with | >> Base64 again and then just grab the relevant parts of the byte array. | >> | >> Joe K. | >> | >> -- | >> Joe Kaplan-MS MVP Directory Services Programming | >> Co-author of "The .NET Developer's Guide to Directory Services | >> Programming" | >> http://www.directoryprogramming.net | >> -- | >> "Dan" <D**@discussions.microsoft.com> wrote in message | >> news:1456564F-FF25-4D1A-B263-5E2A17A10D4C@microsoft.com... | >>> in the patterns and practices guidelines for securing applications it | >>> recommends hashing passwords and using a salt if storing to a database | >>> (i am | >>> ok with this bit). however, it also recommends appending the salt to the | >>> hashed password for simplified storage and then makes the following | >>> statement:- | >>> | >>> This approach means you do not need to store the salt separately. To | >>> verify | >>> a password, you extract the salt from the stored combination of the hash | >>> and | >>> salt value and then recomputed the hash using the salt value and the | >>> plaintext password value obtained from the user. | >>> | >>> my question is, how exactly do you extract the salt from the stored | >>> combination? is it really as simple as knowing in advance that the salt | >>> was x | >>> characters long so you can do an easy substring when extracting? or is | >>> there | >>> another method? | >> | >> | > | > | | thanks guys, i really appreciate the quick response! didnt mean to start a
debate, but all the better for it ;-) cheers dan Show quoteHide quote "William Stacey [MVP]" wrote: > If you have the salt and the hash, the salt does not make attacking your > password much harder (only a tinny bit). Different salt per user only > forces one to crack *each password separately - even if they are the same > clear text password. But it does not slow the algo down much if I have the > salt and can infer the algo used (i.e. hash (pw + salt) or hash(salt+pw)). > In most cases, the attacker does not need or care about all passwords, only > 1. And he can run the algo all week until he finds it (doing millions of > iterations per minute using many dictionaries and combinations, etc). So > the salt does not really help if it is in the clear and with the user's hash > record. Additional protection would be to store the salt encrypted if > possible. Then I can't really do a brute force attack. One could try, but > good luck with that on a crypto random 16 byte salt or greater. > > -- > William Stacey [MVP] > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote > in message news:e9Txl9zuGHA.5084@TK2MSFTNGP04.phx.gbl... > | I'm not sure what you mean here, Rob. Can you explain? > | > | The general recommendation is to salt your hashes, as that makes them very > | difficult to crack brute force if they are somehow stolen. If you are > going > | to salt your hashes, you have to have the salt available when you go to > | compare the hashed value. Where would you recommend storing the salt > | otherwise? The other standard way is in a second column in the table. > | > | Joe K. > | > | -- > | Joe Kaplan-MS MVP Directory Services Programming > | Co-author of "The .NET Developer's Guide to Directory Services > Programming" > | http://www.directoryprogramming.net > | -- > | "Rob R. Ainscough" <roba***@pacbell.net> wrote in message > | news:OZzM3XzuGHA.4688@TK2MSFTNGP06.phx.gbl... > | > But if the source isn't secure what is the point of doing this? And if > | > the source is secure, then there is no pointing is storing the salt this > | > way in the first place. > | > > | > Rob. > | > > | > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> > wrote > | > in message news:OVEeLjwuGHA.5056@TK2MSFTNGP06.phx.gbl... > | >> It really is that simple, but you would tend to do it in bytes instead > of > | >> characters. The hash would be the first X bytes and the salt would be > | >> the remaining bytes, or vice versa. > | >> > | >> If you store the value in the database as a string, make sure you > convert > | >> to Base64. Then, after you read it back out, convert back to byte[] > with > | >> Base64 again and then just grab the relevant parts of the byte array. > | >> > | >> Joe K. > | >> > | >> -- > | >> Joe Kaplan-MS MVP Directory Services Programming > | >> Co-author of "The .NET Developer's Guide to Directory Services > | >> Programming" > | >> http://www.directoryprogramming.net > | >> -- > | >> "Dan" <D**@discussions.microsoft.com> wrote in message > | >> news:1456564F-FF25-4D1A-B263-5E2A17A10D4C@microsoft.com... > | >>> in the patterns and practices guidelines for securing applications it > | >>> recommends hashing passwords and using a salt if storing to a database > | >>> (i am > | >>> ok with this bit). however, it also recommends appending the salt to > the > | >>> hashed password for simplified storage and then makes the following > | >>> statement:- > | >>> > | >>> This approach means you do not need to store the salt separately. To > | >>> verify > | >>> a password, you extract the salt from the stored combination of the > hash > | >>> and > | >>> salt value and then recomputed the hash using the salt value and the > | >>> plaintext password value obtained from the user. > | >>> > | >>> my question is, how exactly do you extract the salt from the stored > | >>> combination? is it really as simple as knowing in advance that the > salt > | >>> was x > | >>> characters long so you can do an easy substring when extracting? or is > | >>> there > | >>> another method? > | >> > | >> > | > > | > > | > | > > > I basically agree with what you are saying. In my mind, it depends on how
much the attacker knows about the data they have stolen/intercepted. For example, for them to use the salt directly, they have to know that it hasn't been encrypted. If the salt is combined with the hash, they have to know what part of the data is the salt and what is the hash. This isn't always easy to do unless the attacker has access to the code that implements the algorithm. If I just steal the data, let's say I get 4 columns that contain some random looking binary data. How do I know what's what? Some of it could be just random numbers left as a decoy! Your point is well-taken though. Joe K. -- Show quoteHide quoteJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "William Stacey [MVP]" <william.sta***@gmail.com> wrote in message news:eWr3LA2uGHA.416@TK2MSFTNGP04.phx.gbl... > If you have the salt and the hash, the salt does not make attacking your > password much harder (only a tinny bit). Different salt per user only > forces one to crack *each password separately - even if they are the same > clear text password. But it does not slow the algo down much if I have > the > salt and can infer the algo used (i.e. hash (pw + salt) or hash(salt+pw)). > In most cases, the attacker does not need or care about all passwords, > only > 1. And he can run the algo all week until he finds it (doing millions of > iterations per minute using many dictionaries and combinations, etc). So > the salt does not really help if it is in the clear and with the user's > hash > record. Additional protection would be to store the salt encrypted if > possible. Then I can't really do a brute force attack. One could try, but > good luck with that on a crypto random 16 byte salt or greater. > > -- > William Stacey [MVP] > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote > in message news:e9Txl9zuGHA.5084@TK2MSFTNGP04.phx.gbl... > | I'm not sure what you mean here, Rob. Can you explain? > | > | The general recommendation is to salt your hashes, as that makes them > very > | difficult to crack brute force if they are somehow stolen. If you are > going > | to salt your hashes, you have to have the salt available when you go to > | compare the hashed value. Where would you recommend storing the salt > | otherwise? The other standard way is in a second column in the table. > | > | Joe K. > | > | -- > | Joe Kaplan-MS MVP Directory Services Programming > | Co-author of "The .NET Developer's Guide to Directory Services > Programming" > | http://www.directoryprogramming.net > | -- > | "Rob R. Ainscough" <roba***@pacbell.net> wrote in message > | news:OZzM3XzuGHA.4688@TK2MSFTNGP06.phx.gbl... > | > But if the source isn't secure what is the point of doing this? And > if > | > the source is secure, then there is no pointing is storing the salt > this > | > way in the first place. > | > > | > Rob. > | > > | > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> > wrote > | > in message news:OVEeLjwuGHA.5056@TK2MSFTNGP06.phx.gbl... > | >> It really is that simple, but you would tend to do it in bytes > instead > of > | >> characters. The hash would be the first X bytes and the salt would > be > | >> the remaining bytes, or vice versa. > | >> > | >> If you store the value in the database as a string, make sure you > convert > | >> to Base64. Then, after you read it back out, convert back to byte[] > with > | >> Base64 again and then just grab the relevant parts of the byte array. > | >> > | >> Joe K. > | >> > | >> -- > | >> Joe Kaplan-MS MVP Directory Services Programming > | >> Co-author of "The .NET Developer's Guide to Directory Services > | >> Programming" > | >> http://www.directoryprogramming.net > | >> -- > | >> "Dan" <D**@discussions.microsoft.com> wrote in message > | >> news:1456564F-FF25-4D1A-B263-5E2A17A10D4C@microsoft.com... > | >>> in the patterns and practices guidelines for securing applications > it > | >>> recommends hashing passwords and using a salt if storing to a > database > | >>> (i am > | >>> ok with this bit). however, it also recommends appending the salt to > the > | >>> hashed password for simplified storage and then makes the following > | >>> statement:- > | >>> > | >>> This approach means you do not need to store the salt separately. To > | >>> verify > | >>> a password, you extract the salt from the stored combination of the > hash > | >>> and > | >>> salt value and then recomputed the hash using the salt value and the > | >>> plaintext password value obtained from the user. > | >>> > | >>> my question is, how exactly do you extract the salt from the stored > | >>> combination? is it really as simple as knowing in advance that the > salt > | >>> was x > | >>> characters long so you can do an easy substring when extracting? or > is > | >>> there > | >>> another method? > | >> > | >> > | > > | > > | > | > > | been encrypted. If the salt is combined with the hash, they have to know I agree. But that is the easy part. Most people are so proud of there | what part of the data is the salt and what is the hash. This isn't always | easy to do unless the attacker has access to the code that implements the | algorithm. security, all it takes is a simple call. Something like " hey, I am concerned about the security of my password, what method do you use to protect it?....". Another way is to just infer it based on my password that I already know. The goal is to protect it from not only the outside, but from people that have access (for right or wrong) to the data (which is normally many more people then you want or need) to the data. After all, they are the one that normally have a motive because they know what that pw can give them. Nobody should know the password except the user. I would try not to use DB passwords at all, but instead do the work required to leverage Windows security and keep a single pw entry point and management point (i.e. AD). Second best, would be something like SRP6a. None of the DB data can be reversed, same passwords do not generate the same results, does not use simple hashes, is wire secure, etc. You have to know the pwd or guess it. And to guess it means you have to run the login procedure which will fail after N number of attempts - unless again you have the DB. If you have the DB you can brute force it, but much harder then simple hashing. | If I just steal the data, let's say I get 4 columns that contain As you know, they have a name for that; "Security via obscurity" - which is | some random looking binary data. How do I know what's what? Some of it | could be just random numbers left as a decoy! concidered by security people to be no security at all. Because once the secret is out, it scales forever - too many current, future, and *past people know it and they love to talk. In summary, simple hash and salt is old and insecure. -- wjs That's good info, especially the stuff about SRP-6a. I had not heard of
that and have put that on my reading list. Thanks. :) What would you recommend for the OP? I'm guessing that he's doing the salted hash thing based on Microsoft's own guidance on the subject (which is apparently outdated). Is there a good .NET-based SRP implementation that he could just use in replacement of the salted hash approach? Joe K. -- Show quoteHide quoteJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "William Stacey [MVP]" <william.sta***@gmail.com> wrote in message news:%23oXppC$uGHA.4512@TK2MSFTNGP05.phx.gbl... > > As you know, they have a name for that; "Security via obscurity" - which > is > concidered by security people to be no security at all. Because once the > secret is out, it scales forever - too many current, future, and *past > people know it and they love to talk. In summary, simple hash and salt > is > old and insecure. > -- > wjs > > Good idea. I should have added that. I could not find one either in c#, so
I wrote one using the rfc and his later papers on updates for SRP6a. http://channel9.msdn.com/ShowPost.aspx?PostID=107763 This sample shows using WSE as the transport, but the core classes can be used for anything like sockets, email, etc. Now that I think about it, I should probably create a Sql2005 UDT to contain the complete server side code to make it easy - that might be interesting. Then you should just need 1 column for everything (I think). You could probably also apply DB crypto to that column, but have not played with those features in the DB, so not sure. He would need to code a little, but it is another option anyway. Interesting stuff. Thanks Joe. -- Show quoteHide quoteWilliam Stacey [MVP] "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote in message news:uqFevw$uGHA.1504@TK2MSFTNGP03.phx.gbl... | That's good info, especially the stuff about SRP-6a. I had not heard of | that and have put that on my reading list. Thanks. :) | | What would you recommend for the OP? I'm guessing that he's doing the | salted hash thing based on Microsoft's own guidance on the subject (which is | apparently outdated). Is there a good .NET-based SRP implementation that he | could just use in replacement of the salted hash approach? | | Joe K. | -- | Joe Kaplan-MS MVP Directory Services Programming | Co-author of "The .NET Developer's Guide to Directory Services Programming" | http://www.directoryprogramming.net | -- | "William Stacey [MVP]" <william.sta***@gmail.com> wrote in message | news:%23oXppC$uGHA.4512@TK2MSFTNGP05.phx.gbl... | > | > As you know, they have a name for that; "Security via obscurity" - which | > is | > concidered by security people to be no security at all. Because once the | > secret is out, it scales forever - too many current, future, and *past | > people know it and they love to talk. In summary, simple hash and salt | > is | > old and insecure. | > -- | > wjs | > | > | | I should also mention no part of the password is every transfered over the
wire or in the server, only known at the client side. That is good for security, but does, however, prevent using things like LogonUser() api which requires a clear password. There is a way around that. You could do a two-phase logon procedure. The first phase is with a well-known password just to get the same random session keys on both sides (this is still secure with the algo believe it or not), then AES encrypt the clear password using the new random session key both sides have. Ever session will generate a different random session key. You can even just use the session key to encrypt the whole session stream until close. That is actually pretty cool. To hack, you would need to actively debug the server to see the clear password in the call to LogonUser(), but that is something I guess you could do with any protocol that eventually calls an api that requires a clear pwd. -- William Stacey [MVP] Hi William,
SRP is a very good scheme when used properly, however, your suggestion to generate random session key with "fixed password" SRP is nothing more than Diffie-Hellman key exchange with a couple of unnecesary complicating details that doesn't contribute to security. As plain D/H "fixed password" SRP will be secure against passive attacker, but totally broken against active attacker. So, for session key you'd better use something else, as for example Merrit/Bellowin's EKE or any other related protocols such as SPEKE/(2) or even authenticated D/H. But even better - I'd rather recommend using SSL or IP/sec for secure session negotiation ... and for transferring the password, and for the rest of what you suggested. Any modification of existing protocol gives a new protocol that can't use any of security proofs of the original protocol and therefore - proving a new protocol secure is a task that is way beyond competency for any non-cryptographer. Developers must use existing protocols (!) as long as existing protocols provide solutions to their problems - but never invent their own protocols! -Valery. http://www.harper.no/valery William Stacey [MVP] wrote: Show quoteHide quote > I should also mention no part of the password is every transfered over the > wire or in the server, only known at the client side. That is good for > security, but does, however, prevent using things like LogonUser() api which > requires a clear password. There is a way around that. You could do a > two-phase logon procedure. The first phase is with a well-known password > just to get the same random session keys on both sides (this is still secure > with the algo believe it or not), then AES encrypt the clear password using > the new random session key both sides have. Ever session will generate a > different random session key. You can even just use the session key to > encrypt the whole session stream until close. That is actually pretty cool. > To hack, you would need to actively debug the server to see the clear > password in the call to LogonUser(), but that is something I guess you could > do with any protocol that eventually calls an api that requires a clear pwd. > > -- > William Stacey [MVP] Hi Valery, you are correct. Forget the second part. I was thinking about
protection of the clear username (u), not the password. If you don't want the *username sent in the clear, you could do a pre-step, by using the well-known password idea and sending the username encrypted. This resists passive knowlege of the username if that is a concern, which could help resist DOS attacks. Then you would just run the protocol as normal to get the shared session keys and authentication against the DB. The protocol is not changed and this was asserted as an idea by the auther somewhere I can't remember (so not trying to invent anything new). The normal protocol, AFAICT, resists known active and passive attacks. Once the protocol is complete, only both sides know the shared session, so you can use AES (or other) for the rest of the session without needing a cert or SSL, which is one of the more interesting features of the protocol. This protocol fits well with a seperate user authentication DB as some folks seem to be using as evidenced from the OP. Thanks for catching that. -- Show quoteHide quoteWilliam Stacey [MVP] "Valery Pryamikov" <val***@harper.no> wrote in message news:1155236286.109613.195960@m79g2000cwm.googlegroups.com... | Hi William, | SRP is a very good scheme when used properly, however, | your suggestion to generate random session key with "fixed password" | SRP is nothing more than Diffie-Hellman key exchange with a couple of | unnecesary complicating details that doesn't contribute to security. As | plain D/H "fixed password" SRP will be secure against passive attacker, | but totally broken against active attacker. | So, for session key you'd better use something else, as for example | Merrit/Bellowin's EKE or any other related protocols such as SPEKE/(2) | or even authenticated D/H. | But even better - I'd rather recommend using SSL or IP/sec for secure | session negotiation ... and for transferring the password, and for the | rest of what you suggested. | Any modification of existing protocol gives a new protocol that can't | use any of security proofs of the original protocol and therefore - | proving a new protocol secure is a task that is way beyond competency | for any non-cryptographer. | Developers must use existing protocols (!) as long as existing | protocols provide solutions to their problems - but never invent their | own protocols! | -Valery. | http://www.harper.no/valery | | William Stacey [MVP] wrote: | > I should also mention no part of the password is every transfered over the | > wire or in the server, only known at the client side. That is good for | > security, but does, however, prevent using things like LogonUser() api which | > requires a clear password. There is a way around that. You could do a | > two-phase logon procedure. The first phase is with a well-known password | > just to get the same random session keys on both sides (this is still secure | > with the algo believe it or not), then AES encrypt the clear password using | > the new random session key both sides have. Ever session will generate a | > different random session key. You can even just use the session key to | > encrypt the whole session stream until close. That is actually pretty cool. | > To hack, you would need to actively debug the server to see the clear | > password in the call to LogonUser(), but that is something I guess you could | > do with any protocol that eventually calls an api that requires a clear pwd. | > | > -- | > William Stacey [MVP] | In SRP the password is unknown. When password is known it is not SRP,
but a variant of D/H. That is btw a part of security proof of SRP - reduction to D/H by using fixed password, and following claim that schema is at least as secure as D/H with further assertion that by using non-fixed secret password the scheme also becames secure against active attackers. -Valery. http://www.harper.no/valery William Stacey [MVP] wrote: Show quoteHide quote > Hi Valery, you are correct. Forget the second part. I was thinking about > protection of the clear username (u), not the password. If you don't want > the *username sent in the clear, you could do a pre-step, by using the > well-known password idea and sending the username encrypted. This resists > passive knowlege of the username if that is a concern, which could help > resist DOS attacks. Then you would just run the protocol as normal to get > the shared session keys and authentication against the DB. The protocol is > not changed and this was asserted as an idea by the auther somewhere I can't > remember (so not trying to invent anything new). The normal protocol, > AFAICT, resists known active and passive attacks. Once the protocol is > complete, only both sides know the shared session, so you can use AES (or > other) for the rest of the session without needing a cert or SSL, which is > one of the more interesting features of the protocol. This protocol fits > well with a seperate user authentication DB as some folks seem to be using > as evidenced from the OP. Thanks for catching that. > > -- > William Stacey [MVP] > > "Valery Pryamikov" <val***@harper.no> wrote in message > news:1155236286.109613.195960@m79g2000cwm.googlegroups.com... > | Hi William, > | SRP is a very good scheme when used properly, however, > | your suggestion to generate random session key with "fixed password" > | SRP is nothing more than Diffie-Hellman key exchange with a couple of > | unnecesary complicating details that doesn't contribute to security. As > | plain D/H "fixed password" SRP will be secure against passive attacker, > | but totally broken against active attacker. > | So, for session key you'd better use something else, as for example > | Merrit/Bellowin's EKE or any other related protocols such as SPEKE/(2) > | or even authenticated D/H. > | But even better - I'd rather recommend using SSL or IP/sec for secure > | session negotiation ... and for transferring the password, and for the > | rest of what you suggested. > | Any modification of existing protocol gives a new protocol that can't > | use any of security proofs of the original protocol and therefore - > | proving a new protocol secure is a task that is way beyond competency > | for any non-cryptographer. > | Developers must use existing protocols (!) as long as existing > | protocols provide solutions to their problems - but never invent their > | own protocols! > | -Valery. > | http://www.harper.no/valery > | > | William Stacey [MVP] wrote: > | > I should also mention no part of the password is every transfered over > the > | > wire or in the server, only known at the client side. That is good for > | > security, but does, however, prevent using things like LogonUser() api > which > | > requires a clear password. There is a way around that. You could do a > | > two-phase logon procedure. The first phase is with a well-known > password > | > just to get the same random session keys on both sides (this is still > secure > | > with the algo believe it or not), then AES encrypt the clear password > using > | > the new random session key both sides have. Ever session will generate a > | > different random session key. You can even just use the session key to > | > encrypt the whole session stream until close. That is actually pretty > cool. > | > To hack, you would need to actively debug the server to see the clear > | > password in the call to LogonUser(), but that is something I guess you > could > | > do with any protocol that eventually calls an api that requires a clear > pwd. > | > > | > -- > | > William Stacey [MVP] > | | In SRP the password is unknown. When password is known it is not SRP, This is what I mean:| but a variant of D/H. That is btw a part of security proof of SRP - http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-12.txt "The client's user name is sent in the clear in the Client Hello message. To avoid sending the user name in the clear, the client could first open a conventional anonymous, or server-authenticated connection, then renegotiate an SRP-authenticated connection with the handshake protected by the first connection." -- William Stacey [MVP] Anonymous and server authenticated connection in this context is just a
SSL/TLS connection (which is not authenticated with SRP). ;-). -Valery. http://www.harper.no/valery William Stacey [MVP] wrote: Show quoteHide quote > | In SRP the password is unknown. When password is known it is not SRP, > | but a variant of D/H. That is btw a part of security proof of SRP - > > This is what I mean: > > http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-12.txt > > "The client's user name is sent in the clear in the Client Hello > message. To avoid sending the user name in the clear, the client > could first open a conventional anonymous, or server-authenticated > connection, then renegotiate an SRP-authenticated connection with the > handshake protected by the first connection." > > -- > William Stacey [MVP] But it could be. You could auth with the server using a well-known account
just to get a session-key to encrypt the username. -- Show quoteHide quoteWilliam Stacey [MVP] "Valery Pryamikov" <val***@harper.no> wrote in message news:1155373883.048419.11160@75g2000cwc.googlegroups.com... | Anonymous and server authenticated connection in this context is just a | SSL/TLS connection (which is not authenticated with SRP). ;-). | | -Valery. | http://www.harper.no/valery | | William Stacey [MVP] wrote: | > | In SRP the password is unknown. When password is known it is not SRP, | > | but a variant of D/H. That is btw a part of security proof of SRP - | > | > This is what I mean: | > | > http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-12.txt | > | > "The client's user name is sent in the clear in the Client Hello | > message. To avoid sending the user name in the clear, the client | > could first open a conventional anonymous, or server-authenticated | > connection, then renegotiate an SRP-authenticated connection with the | > handshake protected by the first connection." | > | > -- | > William Stacey [MVP] | SSL is much better in this context. unauthenticated D/H is vulnerable
to the man-in-the middle, while SSL is not. -Valery. http://www.harper.no/valery William Stacey [MVP] wrote: Show quoteHide quote > But it could be. You could auth with the server using a well-known account > just to get a session-key to encrypt the username. > > -- > William Stacey [MVP] > > "Valery Pryamikov" <val***@harper.no> wrote in message > news:1155373883.048419.11160@75g2000cwc.googlegroups.com... > | Anonymous and server authenticated connection in this context is just a > | SSL/TLS connection (which is not authenticated with SRP). ;-). > | > | -Valery. > | http://www.harper.no/valery > | > | William Stacey [MVP] wrote: > | > | In SRP the password is unknown. When password is known it is not SRP, > | > | but a variant of D/H. That is btw a part of security proof of SRP - > | > > | > This is what I mean: > | > > | > http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-12.txt > | > > | > "The client's user name is sent in the clear in the Client Hello > | > message. To avoid sending the user name in the clear, the client > | > could first open a conventional anonymous, or server-authenticated > | > connection, then renegotiate an SRP-authenticated connection with the > | > handshake protected by the first connection." > | > > | > -- > | > William Stacey [MVP] > | Natually, SSL is good solution. If you have an ssl channel, then there is
no need for this thread as you have an secure channel and could send the logon info in the clear and do something like LogonUser() at the server. The point here, I think, was to auth w/ a custom DB and SRP is a nice solution in that space. The MITM in the context of SRP is possible, not because of DH, but because the attacker would know the well-known server pwd. MITM, is not possible with SRP unless the attacker knows the pwd. -- Show quoteHide quoteWilliam Stacey [MVP] "Valery Pryamikov" <val***@harper.no> wrote in message news:1155454556.493393.16390@75g2000cwc.googlegroups.com... | SSL is much better in this context. unauthenticated D/H is vulnerable | to the man-in-the middle, while SSL is not. | | -Valery. | http://www.harper.no/valery | .... William Stacey [MVP] wrote:
> MITM, is not possible with SRP unless the attacker knows the pwd. Yes, that's correct.-Valery. http://www.harper.no/valery About protecting user name - this could be required for privacy,
however for privacy you should use right privacy enhancing technologies and protocols, such as for example, Brand's certificates. Protocols based on Brand's certificates has provable strong privacy protection (in some cases even unconditionally secure against any polynomially bound adversary). -Valery. http://www.harper.no/valery William Stacey [MVP] wrote: Show quoteHide quote > Hi Valery, you are correct. Forget the second part. I was thinking about > protection of the clear username (u), not the password. If you don't want > the *username sent in the clear, you could do a pre-step, by using the > well-known password idea and sending the username encrypted. This resists > passive knowlege of the username if that is a concern, which could help > resist DOS attacks. Then you would just run the protocol as normal to get > the shared session keys and authentication against the DB. The protocol is > not changed and this was asserted as an idea by the auther somewhere I can't > remember (so not trying to invent anything new). The normal protocol, > AFAICT, resists known active and passive attacks. Once the protocol is > complete, only both sides know the shared session, so you can use AES (or > other) for the rest of the session without needing a cert or SSL, which is > one of the more interesting features of the protocol. This protocol fits > well with a seperate user authentication DB as some folks seem to be using > as evidenced from the OP. Thanks for catching that. > > -- > William Stacey [MVP] > > "Valery Pryamikov" <val***@harper.no> wrote in message > news:1155236286.109613.195960@m79g2000cwm.googlegroups.com... > | Hi William, > | SRP is a very good scheme when used properly, however, > | your suggestion to generate random session key with "fixed password" > | SRP is nothing more than Diffie-Hellman key exchange with a couple of > | unnecesary complicating details that doesn't contribute to security. As > | plain D/H "fixed password" SRP will be secure against passive attacker, > | but totally broken against active attacker. > | So, for session key you'd better use something else, as for example > | Merrit/Bellowin's EKE or any other related protocols such as SPEKE/(2) > | or even authenticated D/H. > | But even better - I'd rather recommend using SSL or IP/sec for secure > | session negotiation ... and for transferring the password, and for the > | rest of what you suggested. > | Any modification of existing protocol gives a new protocol that can't > | use any of security proofs of the original protocol and therefore - > | proving a new protocol secure is a task that is way beyond competency > | for any non-cryptographer. > | Developers must use existing protocols (!) as long as existing > | protocols provide solutions to their problems - but never invent their > | own protocols! > | -Valery. > | http://www.harper.no/valery > | > | William Stacey [MVP] wrote: > | > I should also mention no part of the password is every transfered over > the > | > wire or in the server, only known at the client side. That is good for > | > security, but does, however, prevent using things like LogonUser() api > which > | > requires a clear password. There is a way around that. You could do a > | > two-phase logon procedure. The first phase is with a well-known > password > | > just to get the same random session keys on both sides (this is still > secure > | > with the algo believe it or not), then AES encrypt the clear password > using > | > the new random session key both sides have. Ever session will generate a > | > different random session key. You can even just use the session key to > | > encrypt the whole session stream until close. That is actually pretty > cool. > | > To hack, you would need to actively debug the server to see the clear > | > password in the call to LogonUser(), but that is something I guess you > could > | > do with any protocol that eventually calls an api that requires a clear > pwd. > | > > | > -- > | > William Stacey [MVP] > | That's very cool. Thanks for putting that together. I'll dig into it later
for sure. I do think the SQL 2005 UDT is a good idea, but having a modular library makes it flexible enough that someone else can do that if they want. I hope the OP gets some use out of it too (assuming he's still even following the thread :)). Joe K. -- Show quoteHide quoteJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- "William Stacey [MVP]" <william.sta***@gmail.com> wrote in message news:e%23QBcYAvGHA.3936@TK2MSFTNGP04.phx.gbl... > Good idea. I should have added that. I could not find one either in c#, > so > I wrote one using the rfc and his later papers on updates for SRP6a. > http://channel9.msdn.com/ShowPost.aspx?PostID=107763 > > This sample shows using WSE as the transport, but the core classes can be > used for anything like sockets, email, etc. Now that I think about it, I > should probably create a Sql2005 UDT to contain the complete server side > code to make it easy - that might be interesting. Then you should just > need > 1 column for everything (I think). You could probably also apply DB > crypto > to that column, but have not played with those features in the DB, so not > sure. He would need to code a little, but it is another option anyway. > Interesting stuff. Thanks Joe. > > -- > William Stacey [MVP] > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote > in message news:uqFevw$uGHA.1504@TK2MSFTNGP03.phx.gbl... > | That's good info, especially the stuff about SRP-6a. I had not heard of > | that and have put that on my reading list. Thanks. :) > | > | What would you recommend for the OP? I'm guessing that he's doing the > | salted hash thing based on Microsoft's own guidance on the subject > (which > is > | apparently outdated). Is there a good .NET-based SRP implementation > that > he > | could just use in replacement of the salted hash approach? > | > | Joe K. > | -- > | Joe Kaplan-MS MVP Directory Services Programming > | Co-author of "The .NET Developer's Guide to Directory Services > Programming" > | http://www.directoryprogramming.net > | -- > | "William Stacey [MVP]" <william.sta***@gmail.com> wrote in message > | news:%23oXppC$uGHA.4512@TK2MSFTNGP05.phx.gbl... > | > > | > As you know, they have a name for that; "Security via obscurity" - > which > | > is > | > concidered by security people to be no security at all. Because once > the > | > secret is out, it scales forever - too many current, future, and *past > | > people know it and they love to talk. In summary, simple hash and > salt > | > is > | > old and insecure. > | > -- > | > wjs > | > > | > > | > | > > William Stacey [MVP] wrote:
> If you have the salt and the hash, the salt does not make attacking your There's another bit of protection - appending a random salt to the> password much harder (only a tinny bit). password before hashing will strenghen the password and reduce the risk of a dictionary-based attack. Hi Graven. Not sure you read my post. We are talking about random salt.
It does not reduce dictionary attack. If I have the DB, then I have everything I need (hash and salt) to guess the password. The only thing I need to do is apply my dictionaries in a loop and compare to hash - things computers are very fast at. Simple passwords will be found quickly. Hard passwords (i.e. 6 random digits and characters or phrases) is much harder - but the fact is, most people still use ~simple passwords. -- Show quoteHide quoteWilliam Stacey [MVP] "Graven" <s.klim***@gmail.com> wrote in message news:1155149027.864167.118980@n13g2000cwa.googlegroups.com... | William Stacey [MVP] wrote: | > If you have the salt and the hash, the salt does not make attacking your | > password much harder (only a tinny bit). | | There's another bit of protection - appending a random salt to the | password before hashing will strenghen the password and reduce the risk | of a dictionary-based attack. | Actually, the salts were invented when the computers weren't do quick
and the dictionary attacks were based on comaring the hash with a list of pre-hashed words. William Stacey [MVP] wrote: Show quoteHide quote > Hi Graven. Not sure you read my post. We are talking about random salt. > It does not reduce dictionary attack. If I have the DB, then I have > everything I need (hash and salt) to guess the password. The only thing I > need to do is apply my dictionaries in a loop and compare to hash - things > computers are very fast at. Simple passwords will be found quickly. Hard > passwords (i.e. 6 random digits and characters or phrases) is much harder - > but the fact is, most people still use ~simple passwords. > > -- > William Stacey [MVP] > > "Graven" <s.klim***@gmail.com> wrote in message > news:1155149027.864167.118980@n13g2000cwa.googlegroups.com... > | William Stacey [MVP] wrote: > | > If you have the salt and the hash, the salt does not make attacking your > | > password much harder (only a tinny bit). > | > | There's another bit of protection - appending a random salt to the > | password before hashing will strenghen the password and reduce the risk > | of a dictionary-based attack. > | Hi,
i disagree - salting also helps with pre-computed hash tables which makes "looking up" password a matter of a select statement. Combine salt with iterations to buy even more time - up to a point where it might me infeasible to brute force the password. dominick www.leastprivilege.com Show quoteHide quote > If you have the salt and the hash, the salt does not make attacking > your password much harder (only a tinny bit). Different salt per user > only forces one to crack *each password separately - even if they are > the same clear text password. But it does not slow the algo down much > if I have the salt and can infer the algo used (i.e. hash (pw + salt) > or hash(salt+pw)). In most cases, the attacker does not need or care > about all passwords, only 1. And he can run the algo all week until > he finds it (doing millions of iterations per minute using many > dictionaries and combinations, etc). So the salt does not really help > if it is in the clear and with the user's hash record. Additional > protection would be to store the salt encrypted if possible. Then I > can't really do a brute force attack. One could try, but good luck > with that on a crypto random 16 byte salt or greater. > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> > wrote > in message news:e9Txl9zuGHA.5084@TK2MSFTNGP04.phx.gbl... > | I'm not sure what you mean here, Rob. Can you explain? > | > | The general recommendation is to salt your hashes, as that makes > them very > | difficult to crack brute force if they are somehow stolen. If you > are > going > | to salt your hashes, you have to have the salt available when you go > to > | compare the hashed value. Where would you recommend storing the > salt > | otherwise? The other standard way is in a second column in the > table. > | > | Joe K. > | > | -- > | Joe Kaplan-MS MVP Directory Services Programming > | Co-author of "The .NET Developer's Guide to Directory Services > Programming" > | http://www.directoryprogramming.net > | -- > | "Rob R. Ainscough" <roba***@pacbell.net> wrote in message > | news:OZzM3XzuGHA.4688@TK2MSFTNGP06.phx.gbl... > | > But if the source isn't secure what is the point of doing this? > And if > | > the source is secure, then there is no pointing is storing the > salt this > | > way in the first place. > | > > | > Rob. > | > > | > "Joe Kaplan (MVP - ADSI)" > <joseph.e.kap***@removethis.accenture.com> > wrote > | > in message news:OVEeLjwuGHA.5056@TK2MSFTNGP06.phx.gbl... > | >> It really is that simple, but you would tend to do it in bytes > instead > of > | >> characters. The hash would be the first X bytes and the salt > would be > | >> the remaining bytes, or vice versa. > | >> > | >> If you store the value in the database as a string, make sure you > convert > | >> to Base64. Then, after you read it back out, convert back to > byte[] > with > | >> Base64 again and then just grab the relevant parts of the byte > array. > | >> > | >> Joe K. > | >> > | >> -- > | >> Joe Kaplan-MS MVP Directory Services Programming > | >> Co-author of "The .NET Developer's Guide to Directory Services > | >> Programming" > | >> http://www.directoryprogramming.net > | >> -- > | >> "Dan" <D**@discussions.microsoft.com> wrote in message > | >> news:1456564F-FF25-4D1A-B263-5E2A17A10D4C@microsoft.com... > | >>> in the patterns and practices guidelines for securing > applications it > | >>> recommends hashing passwords and using a salt if storing to a > database > | >>> (i am > | >>> ok with this bit). however, it also recommends appending the > salt to > the > | >>> hashed password for simplified storage and then makes the > following > | >>> statement:- > | >>> > | >>> This approach means you do not need to store the salt > separately. To > | >>> verify > | >>> a password, you extract the salt from the stored combination of > the > hash > | >>> and > | >>> salt value and then recomputed the hash using the salt value and > the > | >>> plaintext password value obtained from the user. > | >>> > | >>> my question is, how exactly do you extract the salt from the > stored > | >>> combination? is it really as simple as knowing in advance that > the > salt > | >>> was x > | >>> characters long so you can do an easy substring when extracting? > or is > | >>> there > | >>> another method? > | >> > | >> > | > > | > > | > | Dominick Baier wrote:
> Hi, Yes, that's correct - salting helps protecting agains time-memory> > i disagree - salting also helps with pre-computed hash tables which makes > "looking up" password a matter of a select statement. Combine salt with iterations > to buy even more time - up to a point where it might me infeasible to brute > force the password. > > dominick > www.leastprivilege.com > trade-off like "rainbow tables" and others. -Valery. http://www.harper.no/valery For attacker, I assume pre-computed hash tables are just not that helpful
anymore and they just assume they need to run-time each one based on the particular hash implementation (as everyone seems to use there own these days). So on my single cpu laptop, I can calc: Simple Sha1 hash: 10 seconds per million guesses. rfc2898 w/ 1000 iterations: 5.5 hours per million. Each 1000 iterations ~doubles the time. So it is still very doable. The other problem is it scales better for the attacker then for the attackee. So the attacker can keep adding cheap machines to distribute the time. You can only add so many iterations to your own security system before it becomes impracticable for responsiveness. -- Show quoteHide quoteWilliam Stacey [MVP] "Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote in message news:4580be63e62a8c891a79ae6a4c0@news.microsoft.com... | Hi, | | i disagree - salting also helps with pre-computed hash tables which makes | "looking up" password a matter of a select statement. Combine salt with iterations | to buy even more time - up to a point where it might me infeasible to brute | force the password. | | dominick | www.leastprivilege.com | | | | > If you have the salt and the hash, the salt does not make attacking | > your password much harder (only a tinny bit). Different salt per user | > only forces one to crack *each password separately - even if they are | > the same clear text password. But it does not slow the algo down much | > if I have the salt and can infer the algo used (i.e. hash (pw + salt) | > or hash(salt+pw)). In most cases, the attacker does not need or care | > about all passwords, only 1. And he can run the algo all week until | > he finds it (doing millions of iterations per minute using many | > dictionaries and combinations, etc). So the salt does not really help | > if it is in the clear and with the user's hash record. Additional | > protection would be to store the salt encrypted if possible. Then I | > can't really do a brute force attack. One could try, but good luck | > with that on a crypto random 16 byte salt or greater. | > | > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> | > wrote | > in message news:e9Txl9zuGHA.5084@TK2MSFTNGP04.phx.gbl... | > | I'm not sure what you mean here, Rob. Can you explain? | > | | > | The general recommendation is to salt your hashes, as that makes | > them very | > | difficult to crack brute force if they are somehow stolen. If you | > are | > going | > | to salt your hashes, you have to have the salt available when you go | > to | > | compare the hashed value. Where would you recommend storing the | > salt | > | otherwise? The other standard way is in a second column in the | > table. | > | | > | Joe K. | > | | > | -- | > | Joe Kaplan-MS MVP Directory Services Programming | > | Co-author of "The .NET Developer's Guide to Directory Services | > Programming" | > | http://www.directoryprogramming.net | > | -- | > | "Rob R. Ainscough" <roba***@pacbell.net> wrote in message | > | news:OZzM3XzuGHA.4688@TK2MSFTNGP06.phx.gbl... | > | > But if the source isn't secure what is the point of doing this? | > And if | > | > the source is secure, then there is no pointing is storing the | > salt this | > | > way in the first place. | > | > | > | > Rob. | > | > | > | > "Joe Kaplan (MVP - ADSI)" | > <joseph.e.kap***@removethis.accenture.com> | > wrote | > | > in message news:OVEeLjwuGHA.5056@TK2MSFTNGP06.phx.gbl... | > | >> It really is that simple, but you would tend to do it in bytes | > instead | > of | > | >> characters. The hash would be the first X bytes and the salt | > would be | > | >> the remaining bytes, or vice versa. | > | >> | > | >> If you store the value in the database as a string, make sure you | > convert | > | >> to Base64. Then, after you read it back out, convert back to | > byte[] | > with | > | >> Base64 again and then just grab the relevant parts of the byte | > array. | > | >> | > | >> Joe K. | > | >> | > | >> -- | > | >> Joe Kaplan-MS MVP Directory Services Programming | > | >> Co-author of "The .NET Developer's Guide to Directory Services | > | >> Programming" | > | >> http://www.directoryprogramming.net | > | >> -- | > | >> "Dan" <D**@discussions.microsoft.com> wrote in message | > | >> news:1456564F-FF25-4D1A-B263-5E2A17A10D4C@microsoft.com... | > | >>> in the patterns and practices guidelines for securing | > applications it | > | >>> recommends hashing passwords and using a salt if storing to a | > database | > | >>> (i am | > | >>> ok with this bit). however, it also recommends appending the | > salt to | > the | > | >>> hashed password for simplified storage and then makes the | > following | > | >>> statement:- | > | >>> | > | >>> This approach means you do not need to store the salt | > separately. To | > | >>> verify | > | >>> a password, you extract the salt from the stored combination of | > the | > hash | > | >>> and | > | >>> salt value and then recomputed the hash using the salt value and | > the | > | >>> plaintext password value obtained from the user. | > | >>> | > | >>> my question is, how exactly do you extract the salt from the | > stored | > | >>> combination? is it really as simple as knowing in advance that | > the | > salt | > | >>> was x | > | >>> characters long so you can do an easy substring when extracting? | > or is | > | >>> there | > | >>> another method? | > | >> | > | >> | > | > | > | > | > | | > | | | 
Other interesting topics
Running .NET 2.0 App from UNC - Windows 2000 Server vs Windows XP Pro
Problems accessing the ASPNETDB.MDF file single sign on from web to smart client Huge problem consuming .net event in JScript code Add Publisher Name to Published VS2005 Project How to programmingly check off "Allow inheritable permissions from load CAPICOM Certificate from X509Certificate Web Service, Authentication, Security & Domains authentication against adsi/ldap Cooecting to SQL server ?? |
|||||||||||||||||||||||
