As a hash function with 'security' of 2 ** 80, it is completely broken. The security is reduced to 2 ** 69. Even though it's still alot of operations, the function is definately broken as it's actual security is less then specified (less then that required for a 'birthday attack').
-- Michael On 4/26/05, Edgar Danielyan <[EMAIL PROTECTED]> wrote: > David, John, > > Although there were some advances on finding collisions in SHA-1 I > wouldn't say it was broken. The attack is fairly unpractical and > woudln't affect absolute majority of SHA-1 uses. Having said that > there are other versions of SHA, e.g. SHA-256 which are not affected > (at present at least). > > Also in addition to the password a "salt" is very often used to > address the risk of memory-speed tradeoff (search on google would give > many references)... In short the best practical option is to use a > hash digest with salt and store the password hash, not the password > itself. > > Regards > > Edgar > > > On 4/25/05, David Crocker <[EMAIL PROTECTED]> wrote: > > I'm by no means an expert in the field of security and Java, but I believe > > that > > the usual technique is to encode the password that the user types using a > > 1-way > > hashing algorithm, then store (and hide/protect) the encoded version and use > > that as the password. If an attacker manages to read the password hash, he > > still > > has to construct a password that will encode to the same value. > > > > There are a number of hashing algorithms available. SHA1 used to be > > considered > > fairly good for this sort of thing, but I understand it has been broken > > recently. > > > > This technique does make it impossible to recover the password; if the > > password > > is lost, it has to be reset to a new one. > > > > David Crocker, Escher Technologies Ltd. > > Consultancy, contracting and tools for dependable software development > > www.eschertech.com > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > > Of john bart > > Sent: 25 April 2005 08:56 > > To: SC-L@securecoding.org > > Subject: [SC-L] Java keystore password storage > > > > Hello to all the list. > > I need some advice on where to store the keystore's password. Right now, i > > have > > something like this in my code: > > > > keystore = KeyStore.getInstance("JKS"); > > keystore.load(new FileInputStream("keystore.jks"),"PASSWORD"); > > > > the question is, where do i store the password string? all of the > > possibilities > > that i thought about are not good enough: > > 1) storing it in the code - obviously not. > > 2) storing it in a seperate config file is also not secure. > > 3) entering the password at runtime is not an option. > > 4) encrypting the password - famous chicken and egg problem (storing the > > encryption key) > > > > Any ideas? > > > > > >
