Never too late. :) Looking at [1], it'll take about 2E64 days to search the SHA256 keyspace with a brute forcer written for a GPU accelerator. Even with 10,000 of them, it'll take way, way too long. Bitcoin coin uses SHA256, so I think it's safe for a while. :)
Yes, SHA512 would be "more safe," but ya gotta ask what you're really getting by going to the bigger key…security is about a balance. If you're using ACS to run a cloud cracking SHA256 passwords, then maybe you should use SHA512 passwords in ACS. ;) John http://www.insidepro.com/eng/egb.shtml On Mar 29, 2013, at 4:36 PM, Justin Grudzien <grudz...@gmail.com<mailto:grudz...@gmail.com>> wrote: I apologize for jumping into this conversation late, but I am new to the developer mailing list. Why would we choose SHA256+salt over SHA512+salt? SHA512+salt's storage is insignificant when compared to SHA256 and the chances of a birthday attack are significantly reduced. As a security professional I would argue for the best possible hashing algorithm available, especially when there is little to no cost. Justin On Mar 29, 2013, at 6:00 PM, "Min Chen" <min.c...@citrix.com<mailto:min.c...@citrix.com>> wrote: ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10039/#review18548 ----------------------------------------------------------- client/tomcatconf/componentContext.xml.in <https://reviews.apache.org/r/10039/#comment38873> This componentContext.xml.in and nonossComponentContext.xml.in should be put into applicationContext.xml since they are the same for nonoss and oss versions. - Min Chen On March 28, 2013, 8:26 p.m., Venkata Siva Vijayendra Bhamidipati wrote: ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10039/ ----------------------------------------------------------- (Updated March 28, 2013, 8:26 p.m.) Review request for cloudstack, Hugo Trippaers, Kelven Yang, and Min Chen. Description ------- Changing default password encoding mechanism from MD5 to SHA256Salted. This addresses bug CS-1734. Diffs ----- api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java 89673ea api/src/org/apache/cloudstack/api/command/admin/user/CreateUserCmd.java fb29e1a api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java 1f31662 client/tomcatconf/componentContext.xml.in 016df0a client/tomcatconf/nonossComponentContext.xml.in 8f8dae5 developer/developer-prefill.sql 6300d35 plugins/user-authenticators/ldap/src/com/cloud/server/auth/LDAPUserAuthenticator.java 61eebe5 plugins/user-authenticators/md5/src/com/cloud/server/auth/MD5UserAuthenticator.java 026125e plugins/user-authenticators/plain-text/src/com/cloud/server/auth/PlainTextUserAuthenticator.java 52e7cb3 plugins/user-authenticators/sha256salted/src/com/cloud/server/auth/SHA256SaltedUserAuthenticator.java 1b29f69 server/src/com/cloud/server/ManagementServerImpl.java b689f93 server/src/com/cloud/user/AccountManagerImpl.java b69f314 Diff: https://reviews.apache.org/r/10039/diff/ Testing ------- Manual testing done for both oss and nonoss components. Both admin and users added later are encoded according to the scheme configured, and authenticated by the same scheme. To change the order of the schemes, modify the following list properties in client/tomcatconf/nonossComponentContext.xml.in or client/tomcatconf/componentContext.xml.in as applicable, to the desired order: <property name="UserAuthenticators"> <list> <ref bean="SHA256SaltedUserAuthenticator"/> <ref bean="MD5UserAuthenticator"/> <ref bean="LDAPUserAuthenticator"/> <ref bean="PlainTextUserAuthenticator"/> </list> </property> <property name="UserPasswordEncoders"> <list> <ref bean="SHA256SaltedUserAuthenticator"/> <ref bean="MD5UserAuthenticator"/> <ref bean="LDAPUserAuthenticator"/> <ref bean="PlainTextUserAuthenticator"/> </list> Thanks, Venkata Siva Vijayendra Bhamidipati Stratosec<http://stratosec.co> - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella<http://twitter.com/johnlkinsella>
