I am using .htaccess files to control access to various Apache2 directories. I have a main "password" file that contains usernames and passwords. All the instructions I have found regarding .htaccess talk about how the passwords added are encrypted. The usernames and passwords are created using the following command line syntax ...
htpasswd -nb username password
What I am wondering is ... do the passwords always need to be encrypted? Could I store usernames and passwords in a plain-text form someonewhere on the system (above the web root)? This would allow me to easily edit user names and passwords via FTP without requiring access to the Shelll (which I do not always have). Thank you.
Uh, it's a really really really bad idea to store the passwords in plaintext, regardless of whether it's supported or not. You could always generate the hashed passwords with a local copy of the htpasswd(1) utility...
Related
I have a web app that uses known username and password combinations to login to external servers. There are multiple username/password combinations used for different services. Right now, they are essentially "hard-coded" into the website code, but, I would like to move this information off the code base for better security.
My initial thought is to store this data in the database which is used to support the website. I want to store it in a way that it is not easily "hackable" (i.e. I'm not going to store it as plain text or as a MD5 hash). Should I follow the same format that I use to store the website user's passwords, where I use a random number generator to create SALT for each password and then store the password as hashed combination of the password and SALT, or would this be overkill?
Generally, storing passwords in the application code is always a bad idea. Moving it outside the code has many advantages including security.
Now storing it either in DB or Configuration Files is a choice you have to take depending on your application.
For full security you should never store passwords in retrievable form. But to login to a external server as in your case, you need to get the actual plain text password, so one way hash will not work for you.
In our product we deal with such situation by using 2 Way SSL Certificates. It is very secure and there is no need to store the passwords.
But if you really need to store the passwords, then I will suggest to use configuration file and let your application read it. You can encrypt the passwords stored in the configuration files (Encrypting the passwords stored in the configuration file will again bring you back to the same question of how to protect the key). The access to the configuration file should be restricted (in Unix, 600 File Permission).
Alternatively, if your web application is Java, then you can consider using JNDI.
After more research, I've decided at this point to follow the ideas here:
Encrypt a Column of Data - SQL Server | Microsoft Docs
...and encrypt/decrypt on the DB inside a Stored Procedure.
Is there a linux command to see the hashed password? Not the actual password but just the hash over it. I have tried showing hash table and such but that has yet to work. Feel like I'm just missing a simple command.
On Unix/Linux systems the hashed passwords of all users are stored into the file /etc/shadow and - for security reasons - this is readable only to root.
Therefore there is no way for an unprivileged user to read its contents.
However, if the NIS service is enabled in your system/network, you can see the hashed passwords in the second column of the output of the command ypcat passwd.
I configured msmtp with my gmail account.
I obviously want to avoid writing my password in plaintext format in the config file.
Luckily enough msmtp offer the option passwordeval which can be used to obtain the password from the output of an an executable.
The question is: how should I use it?
I found here the following suggestion:
passwordeval gpg -d /some/path/to/.msmtp.password.gpg
That doesn't make much sense to me: if someone is able to access my config file he will certainly manage to run such a command and obtain the password from gpg.
So I believe I'm left with the only option of obfuscating the password within the binary executable even if I read almost everywhere that this is bad!
My impossible-to-hack implementation is: if the sendmail process is running output the correct pass, otherwise give a fake pass.
Your suggestions?
Other (more secure) tricks different from storing the pass in the binary file?
From Sukima's comment:
The reason gpg -d works is because it requires the private key of the person the file is encrypted to. So just placing that encrypted file in the public it is still encrypted an only one person (the one with the secret key) can decrypt it. It is assumed that the secret key is locked up on the user's machine and not leaked. It also assumes that they have not setup any agents which cache the unlock password while a hacker has direct access to the same machine. All of which is highly unlikely in 99% of all attacks.
There is not a standard solution on how to save credentials with the constraint of
having to use the credentials in plain text later
and in an unattended way
on a system which is not completely controlled by you (if it is you just set appropriate rights on the files holding the secrets)
You have several solutions, none solves perfectly your problem:
encrypt your credentials in a symmetric way: you need to input the key to decrypt them
encrypt in an asymmetric way: you need to provide your private key, which must be stored somewhere (unattended approach) or keyed in
obfuscate: as you mention, this only protects from some population
get it from somewhere else - you need to identify a way or another your system
You need to take into account which risk is acceptable and go from there.
I've currently thought about a web-driven password database with multiple accounts and the login/passwords stored in a Database engine like MySQL or Oracle. Each password should only be available to some of the users:
User A logs in, creates a new login information and ticks some checkboxes to make this information available to User B and User C. User D and E should not see it.
My first thoughts:
The passwords are stored encrypted in the database.
The main problem here is of course, if you have access to the server you can take a look a the script and detect the decryption algorithm with enables you to de-crypt all the stored passwords at once.
So I thought, each user gets a master password to the password tool which is part of the encryption/decryption algorithm (user enters this master password and the logs in with his own credentials). This had the benefit that a third person could not simply take a look at the scripts to see how they are decrypted exactly as he had to know the master password. But of course it's still possible for users with very limited access to decrypt all of the passwords as they know the master password.
So basically my question is: how is it possible to have a webbased multiple user password database which is not just cracked easily by looking at the plain sources, if someone gets access to the server? Is it possible to make the decryption somehow dependent on the user logins which may officially see the password?
Thanks for any hints on this!
Notice to make things more clear:
It's intended to be a password database where login credentials for different applications are stored and users can log in and see what credentials they have to use for these applications. Like password manager tools like 1Password and so on. It's just a simple lookup table with username/password, it should not insert or interact with 3rd-party applications.
The solution is here:
Is it possible to have encryption with multiple private keys (PHP)?
Use a one way hashing algorithm like MD5 or SHA-1 (or some of its stronger variants). This way, there will be no way to reverse engineer stored passwords.
Have you looked at any products like Passwordstate? All the passwords are encrypted within the database, they can be shared amongst multiple people, all the pages are obfuscated for further protection, and it integrates with Active Directory for authentication.
There's a free 10 user license if you want to check it out.
I've found numerous posts on stackoverflow on how to store user passwords. However, I need to know what is the best way to store a password that my application needs to communicate with another application via the web? Currently, our web app needs to transmit data to a remote website. To upload the data, our web app reads the password from a text file and creates the header with payloads and submits via https.
This password in plain text on the file system is the issue. Is there any way to store the password more securely?
This is a linux os and the application is written in python and is not compiled.
Further clarification:
There are no users involved in this process at all. The password stored in the file system is used by the other web app to authenticate the web app that is making the request. To put it in the words of a commenter below:
"In this case, the application is the client to another remote application."
From the question it seems you need to store password in such a way, that it can be read and used in an automated transaction with another site. You could encrypt the password and store it encrypted in the file, then decrypt it using a key stored elsewhere in your system before using it. This makes difficulties to someone that gets access to the file from using the password, as they now have to find the key and encryption algorithm used, so they can decrypt it.
As defense, more lesser defense is always better than one strong defense that fails when breached. Moreover, I would also secure the file containing the password, rather than the password itself. Configure your webserver to disable possibility to serve the file containing the password, and try to set the process needing the file to run under a separate account, so you can restrict the access to the file to account running the process and admin accounts only.
I don't think you will find a foolproof way to do this. I would suggest a combination of things to achieve 'security by obscurity':
store the password file on a different computer than the one which will use it
store the file path in a separate config file on the app nachine
use permissions to limit access to the config and password files to your process only
audit file access if your system allows it (keep a log of who touched the files)
give the folders and files innocuous names (/usr/joe/kittens.txt?)
block physical access to the computer(s) (offsite hosting, or locked closet, or something)
You can use a two-way key encryption algorithms like RSA,
The password is stored encrypted (by a key, which is stored in the user's brain) on the filesystem, but to decode the password, the user must enter the key.
At the very least you should use permissions (if you are on a filesystem which supports them) to ensure that you are the only one able to read the file.
In addition, if your app is compiled, it would not be too difficult to encrypt the password with a hard-coded passphrase. If the code is not compiled this method wouldn't really be helpful, as a would-be attacker could just read the source and determine the encryption.
You can store it as a result of hash algorithm, this is one way algorithm (eg. MD5 or SHA). On authentication you calc MD5 of password typed by user and checking equality with your stored MD5 password hash for this user. If is equal password is ok.
For more information about hasing algorithms you can visit:
http://en.wikipedia.org/wiki/Secure_Hash_Algorithm
http://en.wikipedia.org/wiki/MD5
Is your web application hosted on a farm? If not then a technology such as DPAPI will allow you to encrypt the password so that it can only be decrypted on the machine it was encrypted on.
From memory there can be problems with using it on a web farm though, as you need to go and re-encrypt the value for each server.
If it is a web farm then you probably want to use some form of RSA encryption as has been suggested in other answers.
EDIT: DPAPI is only good if you are hosting on windows of course...
Protecting the Automatic Logon Password
The LsaStorePrivateData function can be used by server applications to store client and machine passwords.
Windows only
I don't think you are understanding the answers provided. You don't ever store a plain-text password anywhere, nor do you transmit it to another device.
You wrote: Sorry, but the issue is storing a
password on the file system... This
password is needed to authenticate by
the other web app.
You can't count on file system protections to keep plain-text safe which is why others have responded that you need SHA or similar. If you think that a hashed password can't be sufficient for authentication, you don't understand the relevant algorithm:
get password P from user
store encrypted (e.g. salted hash)
password Q someplace relatively
secure
forget P (even clear the buffer you
used to read it)
send Q to remote host H
H gets password P' from user when
needed
H computes Q' from P', compares Q'
to Q for equality