RE: [SC-L] Java keystore password storage
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?
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.)
