More on the two "villians" too. It has a nice description, not overly technical (though inevitable at times) for understanding. Crux of it is remediation is really for CPU vendors to issue firmware updates to protect against these attacks. The OS and affected vendor will "support" with their release to reduce the attack surface or make it harder to exploit.
#TodayILearned: many #security-aware #java developers are wondering how to supply #password #encryption to properties files for application #configurations, like for #Hibernate and #Spring. Obviously the last thing we want is to store our passwords in plain text, when those configuration files are shared publicly on GitHub or via other source control channels.
And if you research, you quickly become aware that "it's turtles all the way down."
Just look at the amount of times questions pertaining to that topic have been posed on StackOverflow, Reddit, G+, Experts Exchange, etc. One would think that the java API designers had thought up a solution by now. (Talking to you, #Oracle and the Java community.)
You'll find #Jasypt. Its library allows us to encrypt and decrypt, and place encrypted values in the Spring application configuration. But it's lacking something important: how does Jasypt keep its encryption keys private?
We need a secure, local place, that we can deploy onto an application server, but not share in source control. That local place needs to provide access to encryption keys.
Then our program can use that key to encrypt and decrypt values in such a way, that only encrypted passwords make it into source code.
Because that local secure place can be a PKCS#12 #keystore, in which case you need an access password. And that's the bottom turtle that doesn't get encrypted.