RE: [SC-L] Java keystore password storage

2005-04-26 Thread Chris Matthews
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 manages to read the password hash,
he still
has to construct a password that will encode to the same value.

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 process can
recover the password, chances are very good an attacker can, and no
cryptographical algorithim will solve that issue.  The system is weak,
not the individual components.

Cheers,
Chris




RE: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Chris Matthews
Dave Paris wrote:

It's also much more likely that the foreman (aka
programming manager) told the builder (programmer) to take shortcuts to

meet time and budget - rather than the programmer taking it upon
themselves to be sloppy and not follow the specifications.

I'd note that there is the question if the programmer was given a
undefined time period in which to deliver said software, would they be
able to deliver code that is free of 'mechanical' (buffer overflows,
pointer math bugs, etc) bugs?.

Additionally, as an industry, we will only really have the answer to the
above question when the programming managers allocate a programmer the
time to truly implement specifications in a mechanically secure way.

But I agree with the premise that a programmer cannot be held
accountable for (design) decisions that were out of his control.  He can
only be accountable for producing mechanically correct behaviour.

-Chris

(Note that references to mechanical bugs are ones that really are
within the programmer's realm to avoid, and include language specific
and language agnostic programming techniques.)