Stephan van Hulst wrote:
Elhanan Maayan wrote:the keys would stores in another file (i'm thinking JCEKS because it allows to store symmetric keys on top of assymetric ones), have the password for that store encrypted in a another file (also part of the config), and the encryption of THAT, would be stored in the machine (using preferences api)
So basically, you have keys in a file protected by keys in another file, protected by keys in another file. Aren't you worried that those last keys are going to be stolen? Shouldn't you encrypt those? And then also the keys used in that step? And so on?
Like Tim said, it's better to trust and rely on the system administrators.
Stephan van Hulst wrote:Usually I don't bother encrypting keys in configuration files on the server. Security is provided by the operating system. If someone unauthorized has access to the files where the keys are stored (encrypted or not), you've already lost.
Matt Wong wrote:well - you can either ask the user for a pbe phrase - or store the data in plain
reason: as long as you try to hide somethin you have to reverse it - and when your code can anyone else can
thats called security by obscurity and is always a bad idea
g tsuji wrote:There was a time gap between dom being started taking shape and the necessity of namespace concept. And then dom itself continued to develop as well... At the time of dom level 1, there wasn't namespace in its final shape and dom level 1 is therefore not namespace aware. And when dom developed to level 2, namespace was then fully incorporated and many other things enhanced as well such as event model. I can say though: without namespace, there is no schema validation. Hence, in the area of schema validation, namespace awareness is a must.
That said, we are in dom level 2 minimum for the validation issue. So dbf.setNamespaceAware(true) is good. However, in the construction of and/or parsing to a dom tree, it is not at all a good idea by mixing level 1 and level 2 methods. It can lead to unpredictable consequences and this is one.
This correction will take out the consequential mixing of methods in different levels and should have the problem rectified.