Putting in a new authenticator/encoder for SHA512 would be good - I'll log a ticket to track it as a separate effort and work on it when time permits. Until then, let's use SHA256 as the default since it's the best we've got implemented as of now.
Regards, Vijay On 3/29/13 5:56 PM, "Justin Grudzien" <grudz...@gmail.com> wrote: >Understandable that SHA256 is good for today but SHA512 is good for >tomorrow and has excellent support in all major languages, products, etc. >Oracle is the only thing I can think of that doesn't support it out of >the box. > >I agree on balance but I can certainly spare the 32 bytes of storage. :) > >Justin > >On Mar 29, 2013, at 7:23 PM, John Kinsella <j...@stratosec.co> wrote: > >> 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/LDAPUserAuthen >>ticator.java 61eebe5 >> >>plugins/user-authenticators/md5/src/com/cloud/server/auth/MD5UserAuthenti >>cator.java 026125e >> >>plugins/user-authenticators/plain-text/src/com/cloud/server/auth/PlainTex >>tUserAuthenticator.java 52e7cb3 >> >>plugins/user-authenticators/sha256salted/src/com/cloud/server/auth/SHA256 >>SaltedUserAuthenticator.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> >>
