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: [email protected] > 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? > >
