7:50 a.m.
I'm going to see if I can tweek this server-side installer builder servlet some more
to accept FORM POST rather than GET.
I don't like the idea that we have to put passwords and things in a query string on a
URL since web servers usually log URLs in their log files (and thus we'd have
sensitive passwords being logged in some log file out on the file system).
I'm also going to look into an optional parameter you can pass in to encode the
passwords using a given random-key or something. You would then pass that in to the
installer to "decode" the passwords that the installer then uses.
For example:
http://localhost:8080/hawkular/wildfly-agent/download?installer=true&...
I'll then do something to encrypt the passwords (not just the hawkular password and
secret key but also the key/keystore password if one is provided) before writing them to
the installer .properties file. When you run the installer, you have to provide that
encryptionSeed to the installer somehow (either pass it in as a cmdline option or have the
installer ask on stdin).
This encryptionSeed isn't as sensitive as the passwords, since its used one time only
during installation. So even if that is logged or captured in the bash history, its not
that much of a problem - you can delete the installer jar and download another installer
with a different encryptionSeed to render the original encrypionSeed useless.
Before I do this encryptionSeed thing - what are your thoughts on that? Any other better
ideas?
9:27 a.m.
| I'm going to see if I can tweek this server-side installer builder servlet
| some more to accept FORM POST rather than GET.
+1 on doing it in doPost()
| I don't like the idea that we have to put passwords and things in a query
| string on a URL since web servers usually log URLs in their log files (and
| thus we'd have sensitive passwords being logged in some log file out on the
| file system).
|
| I'm also going to look into an optional parameter you can pass in to encode
| the passwords using a given random-key or something. You would then pass
| that in to the installer to "decode" the passwords that the installer then
| uses.
|
| For example:
|
|
http://localhost:8080/hawkular/wildfly-agent/download?installer=true&...
|
| I'll then do something to encrypt the passwords (not just the hawkular
| password and secret key but also the key/keystore password if one is
| provided) before writing them to the installer .properties file. When you
| run the installer, you have to provide that encryptionSeed to the installer
| somehow (either pass it in as a cmdline option or have the installer ask on
| stdin).
|
| This encryptionSeed isn't as sensitive as the passwords, since its used one
| time only during installation. So even if that is logged or captured in the
| bash history, its not that much of a problem - you can delete the installer
| jar and download another installer with a different encryptionSeed to render
| the original encrypionSeed useless.
|
| Before I do this encryptionSeed thing - what are your thoughts on that? Any
| other better ideas?
I like the idea. Rather than asking user for encryptionSeed in the ui we can create simple
canvas where user will move with mouse cursor for, say, 3 seconds to create some entropy
and calculate a hash from the sequence of points (taken in some times or any other
method).
All in all, it's still not super secure, because if the hawkular is not deployed on
https, anyone can listen the encrypted stuff and the seed in the POST request, check the
source code and use the decrypt(seed, secret)
jk
3280
days inactive
3280
days old
1 comments
2 participants
participants (2)
-
Jiri Kremser -
John Mazzitelli