I am learning to use maven password encryption capabilities and I would like to know how to choose the parameter <password>. There are two things that I don't understand:
1) mvn --encrypt-master-password foobar will always give a different encrypted master password.
Since the encrypted master password is always different, I see only two possibilities:
A local property is stored somewhere so that it can be used to decrypt the encrypted master password to get the master password. That means that our encrypted server passwords can only be used locally.
Nothing is stored and the master password is useless and doesn't matter at all.
So, my questions here are:
What is stored locally? Will my master password remain safe? Is there a third possibility I didn't think of?
2) On the maven website, it is written:
Also note that the encrypted passwords can be decrypted by someone that has the master password and settings security file. Keep this file secure (or stored separately) if you expect the possibility that the settings.xml file may be retrieved.
If the settings security file is the thing to protect, why should I bother choosing a strong master password? Can't I just use foobar and keep my settings security file safe?
Also, it looks like someone with the two files (settings security file and settings file) would not need the master password to connect to the maven servers. He could use our identity without knowing the passwords. The master password is "only" needed to decrypt the servers passwords (to get them plain text). But then again, protecting the settings security file should be the way to go and the master password would remain useless.
My questions:
How important is the master password? Have I got to remember it? Can I use a long random phrase and forget it forever?
PS: I couldn't find my answer here.
First password is used to generated the master password only, then you can forget it. It is generated using encryption mechanisms and pseudo-random component. As a consequence of that, it should not be possible to decipher it. There is nothing else stored locally than your master password in your security-settings file and it won't be ever prompted or asked again.
This master password is used to cipher and decipher passwords in your settings file. It has the same value as an user-introduced password, but it is almost impossible to deduce it.
Then:
There is nothing else stored locally than your master password in your security-settings file and it won't be ever prompted or asked again. All the safety resides in the safety of the security-settings file.
The master password is not really important and you can forget immediately. You can use whatever you want.
I don't like this approach to protect my password and I would like having a real password cyphering mechanism with a real master password not stored. Public-private key with password strategies seems to be better.
Related
I have a machine which I want to find where my password hash is stored.
the set command returns details about the account and shows that it is connected to a domain however it doesn't show in net user. As well as this on advanced system settings -> User profiles the account shows as type: local and Status: local.
It seems to be a domain user however windows doesn't think it's on a domain.
Because of this searching for hashes has only brought up dead ends. They aren't in the SAM file and they aren't in SECURITY. I also tried password recovery software and the account simply didn't show.
I could see the correct hash through sekurlsa::LogonPasswords full - specifically serkurlsa::msv with mimikatz but now I would like to know where they are stored.
I know they are cached somewhere as I can login without internet, so I think I'm specifically looking for this file.
A brief search of the command suggests they are in the SAM database but I know they aren't.
Any assistance would be appreciated.
I feel like I'm completely missing the point of the new JCEKS keystore format in Wildfly. Maybe you can set me straight.
The way that we have Wildfly configured (and much of the internet instructs us to, for example):
We put the standard keystore entries in a standard Java Key Store ("keystore.jks") file with a password ("jks_pw")
We then create a JCEKS keystore ("keystore.jceks") with a password, salt, and round-count ("jceks_s_n").
We then put "pks_pw" into "keystore.jceks"
We then add the JCEKS password/etc ("jceks_s_n") into our jboss config (standalone.xml) as plain text, defining a entry
We then add a reference to the vault-stored JKS password to our jboss https connector (standalone.xml), as "password="${VAULT::jks::jks::1}".
What the heck did all of that accomplish???
If we just used a JKS file and a password embedded in standalone.xml, the system is susceptible to:
An attacker getting a copy of standalone.xml and the JKS file, in which case all secrets are known.
An attacker getting a copy of the JKS file, in which case an attacker can use brute-force or lookup table attacks.
If we use a JCEKS container in the way described, the system is susceptible to:
(SAME) An attacker getting a copy of standalone.xml, the JKS/JCEKS files, in which case all secrets are known.
(SAME) An attacker getting a copy of the JKS file, in which case an attacker can use brute-force or lookup table attacks.
This would sort of make sense if we put the actual certs inside of the JCEKS file, in which case brute-force and lookup table attacks would be harder in the second case of attack, but so far I haven't found a way to use a JCEKS-formatted keystore directly with an https connector.
Really, the only reason I care too much about this is that we apparently have a security requirement to use the "vault", but it seems pointless.
UPDATE: It is worth noting that by using the vault you're using a "masked" password to the vault in your jboss config file, but I can't figure out what this means. Apparently your masked-password + salt + rounds can unlock the JCEKS keystore (source), so I'm not sure what exactly masking accomplishes. It just seems like a third level of redirection. I've got to be missing something...
JBoss states that the security mechanism behind "vault" is security by obscurity (https://developer.jboss.org/wiki/JBossAS7SecuringPasswords)
How secure is this?
The default implementation of the vault utlizes a Java KeyStore. Its configuration uses Password Based Encryption, which is security by obscurity. This is not 100% security. It only gets away from the problem of clear text passwords in configuration files. There is always a weak link. (As mentallurg suggests in the comments, the keystore password is the weakest link).
Ideally, 3rd party ISV robust implementations of Vaults should provide the necessary security.
Vault uses an unknown password and algorithm perform a symmetric encryption of the keystore password. Without a HSM, you will always face the problem of "where store the, e.g., datasource password". So normally you'd define a property file with an Access-Control-List and store the encoded password there.
The vault just increases the effort of getting the secured password, leaving the attacker to either read the pw in-memory or reverse-engineer the vault encryption algorithm + key.
It is important to to know that the security mechanism behind "vault" is security by obscurity, which means you are just masking your sensetive data. It means if an attacker have access to your standalone.xml and the keystore, he can easily read all your data.
vault "increases the effort" -> the attacker cannot see them directly but with some (little bit) effort.
I need to change the password on a user for over a hundred system. I want to do this with ansible. Which is easy. However the user module on ansible requires a hashed password. I am concerned because there are a few older hosts which may not support newer types of hashing. I want to be able to programmatically identify what password hashing algorithms are available, and use the appropriate password hash to change. Or is there perhaps a better way to handle this whole sale.
I have considered the following:
echo username:password | chpasswd
and run that using the command module. That should use whatever the default algorithm is. Is there any cause for concern with this method?
In my mind, the ideal way would be to figure the supported hashes for each machine and then generate the proper hash for each machine.
The approach you list should work Just make sure you at "no_log: yes" to your task to ensure the password doesn't end up in the log file.
With either approach you're going to need have a way of getting the password(s) into ansible to use with the user module. Not sure if the passwords will be in a CSV file, yaml file or some other format. You could consider using vault to lock things down a bit more.
I wrote a helper script in Ruby to handle my file synchronization through some servers. It was used only in my intranet and authentication was made by SSH keys. But now I want to use it where I can't use SSH keys and I want to store the passwords in a config file.
I know, there are some encryption libraries like bcrypt or OpenSSL, but I have a problem with that:
I start my script and enter my passphrase and it is stored in a variable to decrypt my passwords.
My code is open source.
So everybody, who has access with my user to my computer (which would be the first barrier, which I'd like to extend) and looks into the memory (where my passphrase is stored) can decrypt my password file. How is that handled in applications which are relevant to security?
Edith says as a reply to DevDude (but here, because I want to keep my specifications in my question):
But then this configuration file would be plain text and not encrypted. And when I encrypt this file there are two more issues in my opinion:
The super_secret_pwd would be stored in a variable, so when I would search in the memory of the computer, I would find it, wouldnt I?
The master password for encryption would be in the memory as plain text, too.
So the big question is: Is it possible to read plain text variables from the memory? As I know it is possible in C and a big security issue.
What you are looking for is to use a YAML file with the password/API keys. and never check this file into your repo.
Then you can reference this file on your initializers, and maybe make the password a global variable or x, use configatron, etc.
This is basically how production applications work, they read their important settings from a YAML file stored on the server itself.
This is what I use:
#c = configatron
# Per environment settings
app_settings = YAML.load_file('config/secret_stuff.yml')
#c.password = app_settings['super_secret_pwd']
Do not use ENVIRONMENT variables because they have all sort of security issues. They are an antipattern.
in my ruby script I need to pass user name and
password as a plain text in a form in order to log in. Both user name and password are currently stored in my script.
I have no control over the server I log in from the script. The script is localy working fine and in the future I want to move to onto my
webhosting provider and run it from there (I have ssh access)
using cron. Is there any way/method how to
protect the password in case somebody gets access to this script by any chance?
The more I think about this, the more I think you must trust your hosting service. I would make sure the hosting service has "skin in the game": That is, that they host enough "high profile" accounts that being found untrustworthy would be very costly to them (in lost accounts and sales).
And whether or not you think the hosting service is trustworthy, you ought have a plan in case the target account is compromised. Who will you notify, how will you get that account deactivated, etc.
The only technological solution I can think of--you log on manually, capture the cookie, and provide that cookie to the script--protects the password, but presumably a hostile host could use that cookie to do any damage he wanted on the target system using whatever privileges are attached to that cookie, including changing your password. So it's no solution at all.
Oh, speaking of privileges: Can the task you need to automate be accomplished with a target account that has lowered privileges, such as a read-only account, or one that cannot make any changes to its profile? Having only your low-privilege credentials on the hosting service would lower your risk (or "exposure," as the polysyllabic crowd likes to say).
Prior answer, found to be unworkable, below the line.
You can encrypt the user id and password using yet another password. In order to run, the script has to be provided with it's password. It uses that password to decrypt the web service's user name and password. Make sure that the script's password doesn't get stored anywhere, but only held in memory and only for long enough to decrypt the ultimate user id and password.
If it really matters, make sure your connection to run the script is crypto (ssh, ssl, etc.), and make sure the script only uses https to log on.
That doesn't make you invulnerable to someone with root privileges on the box (at some point, the plaintext user-id and password will be in memory, and therefore vulnerable), but it does make it take more work for them to be able to get the user-id/password.
Updated: The requirement that this be automated makes the above solution no good.
If an automated script needs to run something with a password, then you either have to have it readable by the script (which opens up the possibility of someone else reading it) or else not provide it in automation.
The trick is to bypass the "Automation" part by having a one time startup: run the script as a small continual process that will wake up periodically and run. Have the process ask for the password on startup or via some other kind of API request (not on the command line!).
If the server reboots, the password is lost until you log in and enter the password again. This way, the password is only in memory, not on the file system.
You might want a cron job to check on the process and alert you if it is not running.
If you need to pass the password onwards to a form that you presumably can't alter to use a more secure scheme, there's little you can do besides obfuscate the password so that it's not immediately obvious. However, anyone with access to the script itself can simply find where it is passed to to the form and insert a command to print the password there — it needs to be “decrypted” at that point for you to pass it on, no matter what.
To protect it from non-programmers, you could XOR it with something or rotate the letters by some amount, but I wouldn't spend too much time on this as it will be futile against pretty much anyone with a rudimentary understanding of programming. Instead, protect the script itself from other users (set file access rights properly, don't put it in a web-visible directory, etc). And if you do not trust the server's administration, do not upload it there!
You should store a hashed version of the password in your database. A hash is a one way encryption, so it is impossible to use logic to guess the password from the hashed password.
Create a method to hash the password, and do something like this:
require "digest/sha1"
class User
attr_accessor :password
def initialize(password)
#password = hash_password(password)
end
def hash_password(password)
Digest::SHA1.hexdigest(password)
end
def valid_password?(password)
#password == hash_password(password)
end
end
u = User.new("12345")
p u.password # => "8cb2237d0679ca88db6464eac60da96345513964"
p u.valid_password?("not valid") # => false
p u.valid_password?("12345") # => true
When you get the plain text password from the form, you pass it to your valid_password? method. This will do the same one-way encryption as it did when the password was stored. So the one way encrypted passwords are compared. This means that you never store a reference to the actual password anywhere, which is a big win.