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] Java keystore password storage
> 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) encrypting the password - famous chicken and egg problem (storing the encryption key) Indeed: this is not a solution, but rather a complication of the process for no real gain (as you've described it). > 3) entering the password at runtime is not an option. This is problably the safest/securest solution. Given how you've worded this, I would suspect that you want the system to be able to start by itself. This implies the system bootstrapping it's own security chain, which to my limited knowledge is not only not secure, but pretty pointless as there are easier methods to achieve the end goal with the exact same security level (for example, storing your keystore unencrypted but with filesystem permissions which do not permit anyone but the application of accessing it). It would also be prudent to point out that most likely any way you will think of to hide/secure/obfusticate the secret needed to access the keystore such that your application can automatically gain access to the keystore, an attacker can mimic this set of operations and gain access to the ketstore at well. 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.)
