On Tue, Apr 26, 2005 at 11:28:46AM -0400, Chris Matthews wrote:
> David Crocker wrote:
>
> At issue is not the mechanical method of storing the password; it is the
> fundamental insecurity of storing a password such that an automated
> process may recover/use said password. If an automated proces
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
David Crocker 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
Dear Michael,
On 4/26/05, Michael Silk <[EMAIL PROTECTED]> wrote:
> 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 sp
At 7:20 PM -0700 4/25/05, Blue Boar wrote:
>David Crocker 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 enco
David Crocker 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
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 lea
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 passw
A little more information would be helpful. What kind of application are
you writing? What is the platform? Is there a secure database or
directory available anywhere in the infrastructure to which the
application has access?
If it's a client, is there a CD reader? If so, you could store the
passw
john bart wrote:
> Hello to all the list.
> I need some advice on where to store the keystore's password.
I don't know the Java functions you're asking about. Looks like it's
decrypting a file?
It's not possible to securely store the password. If a program can
decrypt the file, then a program c
Well, you have provided very little useful information about the
application and its threat model. So, knowing what to suggest is
difficult. Can you say more?
FWIW, we used to use the old C function memfrob to obscure passwords
in code when we couldn't avoid putting them there. At least that way
> 1) storing it in the code - obviously not.
I concur :)
> 2) storing it in a seperate config file is also not secure.
Definitely a possibility. The question now becomes: is this secure
"enough"? (filesystem permissions, mitigating the problem to the level
of the system administrators).
> 4)
12 matches
Mail list logo
