Since 5.5 will contain a simpler hashing strategy i think that should be used in the future, and maybe until then it wont be that bad to use the MessageDigest.
Den torsdag den 21. april 2011 18.39.24 UTC+2 skrev Jeremy Mikola: > > Just wanted to bump this, as I was talking to Johannes about it today. > Over the past week, I was reading a few articles on password storage: > > - http://codahale.com/how-to-safely-store-a-password/ > - http://adrianschneider.ca/2011/04/securely-storing-passwords-in-php/ > - http://apps.ycombinator.com/item?id=2450972 > - http://www.openwall.com/phpass/ > > The take-away is that when it comes to hashing, speed is the enemy. Using > bcrypt, we can introduce a load factor that makes hashing take a full > second (for example). Contrast to shaXXX methods, which can be run millions > of times in the same time-frame. I realize MessageDigestEncoder in Security > component implements stretching to add computational complexity, which is > great, but I think crypt() support would be a valuable addition via a new > encoder class. > > PHP's crypt() seems to have great cross-platform compatibility after > PHP5.3, which makes a library like phpass unnecessary. While the issue of > inter-language compatibility is probably still open since you guys last > discussed this in Janurary, I think this is worth pursuing. Speaking just > about my technology stack, we have associated Java apps and there are > definitely mature bcrypt libraries available. The option of a higher level > of security would be helpful for apps that need to meet > stricter-than-normal regulations. One article I read, but misplaced the > link to, was speaking about bcrypt in the context of PCI-compliance. > > Lastly, I very much like how PHP's crypt() function uses a single string > to store the strategy, its parameters, the salt and hashed password. > Contrast this to the current MessageDigestEncoder, which uses application > configuration to infer the hash algorithm and iterations. Things like salt > combining are hard-coded, and for algorithms that vary by user we have to > rely on something like FOS\UserBundle. > > In the interest of portability between PHP applications, being able to > store crypt()'s argument in the "password" field of a User model is > tremendously convenient. > > Igor, if you'd like to discuss some ideas and collaborate on an encoder > class for Security component, I'm interested. > > On Tue, Jan 18, 2011 at 5:29 AM, Igor Wiedler <ig...@wiedler.ch<javascript:> > > wrote: > >> I have done a little research on the various bcrypt drivers for other >> languages. There are tons available, including for python, c#, ruby, >> java, perl, erlang. To be fair most of them appear to be unstable. >> Taking that into account it may indeed be a bad idea to make it the >> default. >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to symfon...@googlegroups.com<javascript:> >> To unsubscribe from this group, send email to >> symfony-devs...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en >> > > > > -- > jeremy mikola > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
