I am trying to implement BCrypt password encryption using Spring Security. For some reason the password validation is failing for what should be a valid password. The password was created in the same app, and passes the authentication check when I hard code it in a unit test. But, for some reason when it is running on the server it fails. I have checked that it's using the same JRE, the same number of iterations (stored in the hash). I tried reducing it to the bare minimum of code to figure out what's wrong. I am stuck at the point where this statement:
BCrypt.checkpw("password123", "$2a$10$kyRMcxNqagw.ny369X4AsumV4cvHt4Usfvm.rGNDRnxP2SLKioFhu")
returns true when run in a unit test, but fails when run in my PasswordEncoder live on the server. Any ideas on why this is failing?
I figured out my mistake. At one point our code was converting passwords to uppercase. I removed it some places, but missed one. So comparing all caps password to mixed case password failed (as one would expect it should).
I'm currently developing a new application, I had made one in the past and I had done all the users manually but now I'm looking to use the best way possible to implement my users. I had thought in the past of using the gem but because of time reasons I didn't have the time to implement it, now that I'm starting fresh I wanted to start using the gem to optimize and use what the gem has to offer, since I really liked it.
Anyway, my issue is, for security reasons since I will be passing parameters through mobile I will be encrypting the password to pass it to my application, and then with that encrypted password I will encrypt it once again to compare it to the encrypted password, so what I wanted was a way to encrypt the password before devise encrypts it, that way when the mobile app passes the encrypted password it will match to the previous encryption.
I tried a before_save on the Model, without luck, it just saved the encrypted_password empty, I'm not sure why.
tl;dr I need to encrypt before the gem, tried to do it with before_save/before_create on the model but it didn't work, anyone knows any way to do it?
Consider the following fact: If you encrypt the password before sending it with a method which allows you to decrypt it at server level, then this means your method is not one-way and the password sent may be decrypted by other person using a middle-man attack. Then you are not safe at all.
It is much better to use HTTPS/SSL to send this kind of sensitive data. It encrypts all you send at transport level and does this in a way better than anything you can implement by yourself, no offense meant.
How does it work, that devise knows salts for encrypted passwords? Where does it store these hashes and how is that safe?
This is one of the main files for creating passwords: Devise::DatabaseAuthenticatable
Salt is not stored in the database, it is a string generated by this C program that is run by the BCrypt::Engine.generate_salt() function __bc_salt:
prefix = "$2a$05$CCCCCCCCCCCCCCCCCCCCC.E5YPO9kmyuRGyh0XouQYb4YMJKvyOeW"
__bc_salt(prefix, cost, OpenSSL::Random.random_bytes(MAX_SALT_LENGTH))
This can be found here:
BCrypt::Engine
With some other interesting code here: BCrypt::Password
From what I can gather though, the salt itself is the 29 characters that appear after the third $ in the encrypted password. This alone cannot tell you the password though, since you also need to know the pepper which is based on your apps secret key (usually stored in your /config/initializers/secret_token.rb)
Conclusion: In order to decrypt a password, one would have to be using the right version of BCrypt, have obtained the secret token from the app, and have the encrypted password, and I think that at that point, user passwords are probably the least of your security concerns, so I think its pretty safe.
Recently I have changed my authentication system to devise. I want to migrate my existing user data to this new system. Previous one was using SHA256 hash to save password. As I know this encryption is one way so in that case what will be the best way to migrate users data to new system. Devise support SHA512 encryption as well but not SHA256 as I know.
Simply upping the hash size isn't buying much security. Please read up on intreated hashes and salting.
Traditionally, you upgrade a password upon the user changing their password. The type of password is either stored with the password (common format: $type$salt$hashpassword), or in an adjacent column, allowing you detect which algorithm to use.
Whether you force users to change their password is your choice.
When a user enters their password (logs in), you can create a devise account for them automatically. That's probably the easiest way to migrate.
I need to store database passwords in a config file. For obvious reasons, I want to encrypt them (preferably with AES). Does anyone know a Delphi implementation that is easy to introduce into an existing project with > 10,000 lines of historically grown (URGH!) source code?
Clarification: Easy means adding the unit to the project, adding max. 5 lines of code where the config file is read and be done with it. Should not take more than 15 minutes.
Another clarification: The password is needed in order to create a connection to the db, not to support a user management scheme for the application. So using hashes does not help. The db engine checks if the password is valid, not the app.
I second the recommendation for David Barton's DCPCrypt library. I've used it successfuly in several projects, and it won't take more than 15 minutes after you've read the usage examples. It uses MIT license, so you can use it freely in commercial projects and otherwise. DCPCrypt implements a number of algorithms, including Rijndael, which is AES.
There are many googlable stand-alone (single-unit) implementations too - the question is which one you trust, unless you are prepared to verify the correctedness of a particular library yourself.
For typical authentication purposes, you don't need to store the passwords, you only need to check if the password entered by the user is correct. If that's your case then you can just store a hash signature (e.g. MD5) instead and compare it with the signature of the entered password. If the two signatures match the entered password is correct.
Storing encrypted passwords may be dangerous because if someone gets your "master" password they can retrieve passwords of all your users.
If you decide to use MD5 you can use MessageDigest_5.pas which comes with Delphi (at least it's included with my copy of Delphi 2007). There are also other implementations with Delphi source code you can choose from.
I think Turbopower LockBox is an excellent library for criptography:
http://sourceforge.net/projects/tplockbox/
I don't know if it's too big for your uses but it is very easy to use and you can encrypt a string with 5 lines of code. It is all in the examples.
TOndrej has the right approach. You should never store a password using a reversible cypher. As it was correctly pointed out, if your "master" key were ever compromised, the entire system is compromised. Using a non-reversible hash, such as MD5, is much more secure and you can store the hashed value as clear text. Simply hash the entered password and then compare it with the stored hash.
I've always user Turbopower Lockbox. It works well, and very easy to use. I actually use it for exactly the same thing, storing a password in a config text file.
http://sourceforge.net/projects/tplockbox/
TurboPower LockBox 3 (http://lockbox.seanbdurkin.id.au/) uses automatic salting.
I recommend against Barton's DCPCrypt because the IV's are not salted. In some situations this is a very serious sercurity flaw.
Contrary to an earlier commment, LB3's implementation of AES is fully compliant with the standard.
I've used this library, really quick to add. But wiki shows few more solutions.
Even if you encrypt, it seems to me that your decryption key as well as the encrypted password will both be in your executable, which means that in no way is just security by obscurity. Anyone can take the decryption key and the encrypted passwords and generate the raw passwords.
What you want is a one-way hash.
Just a reminder.
If you don´t need to interoperate with others crypt libs, then DCP or LockBox would do the job.
BUT
if you need it to be fully compliant with the rinjdael specs, forget free components, they´re kinda "lousy" most of the time.
As others have pointed out, for authentication purposes you should avoid storing the passwords using reversible encryption, i.e. you should only store the password hash and check the hash of the user-supplied password against the hash you have stored. However, that approach has a drawback: it's vulnerable to rainbow table attacks, should an attacker get hold of your password store database.
What you should do is store the hashes of a pre-chosen (and secret) salt value + the password. I.e., concatenate the salt and the password, hash the result, and store this hash. When authenticating, do the same - concatenate your salt value and the user-supplied password, hash, then check for equality. This makes rainbow table attacks unfeasible.
Of course, if the user send passwords across the network (for example, if you're working on a web or client-server application), then you should not send the password in clear text across, so instead of storing hash(salt + password) you should store and check against hash(salt + hash(password)), and have your client pre-hash the user-supplied password and send that one across the network. This protects your user's password as well, should the user (as many do) re-use the same password for multiple purposes.
I reccomend using some type of salt. Do not store crypt(password) in config file, but insted of this store crypt(salt + password). As 'salt' you can use something that is required to open database, eg. db_name+user_name. For crypt function you can use some well known algortithm as AES, Idea, DES, or something as simple as xoring each byte with byte from some other string, that string will be your key. To make it more different to solve you can use some random bytes, and store them.
So to store:
init_str := 5 random bytes
new_password := salt + password // salt := db_name + user_name
crypted_password = xor_bytes(init_str + new_password, 'my keyphrase')
crypted_password := init_str + crypted_password
store crypted_password in config, as this will be bytes you can hexify or base64 it
And to connect:
split data read from config into init_str and crypted_password
new_password = xor_bytes(init_str + crypted_password, 'my keyphrase')
password := remove (db_name + user_name) from new_password
Nick is of course right - I just assume you know what you are doing when you say you want to spend all of 15 minutes on implementing a security solution. The DCPCrypt library also implements a number of hashing algorithms if you decide to go that (better) route.
A couple of solutions:
Don't store the password at all. If
the database supports integrated
authentication, use it. The process
can be set to run with a specific
identity, and be automatically
authenticated by the database
Use Windows certificate stores and a
certificate to encrypt your password.
If you store the key used to crypt
your password in your application,
you have very little security anyway,
you have to protect the key also.
You need to store it in a place where only the current user has acccess too.
Basically there are two ways to do this:
Store it in an EFS encrypted file.
Store it in the secure local storage.
Internet Explorer uses 2. But if you can get local access, you can decrypt both 1. and 2. if you have the right master key and algorithm (for instance, iepv can get at the Internet Explorer passwords).
So:
If you can, avoid storing passwords.
Look for alternatives (like Windows authentication, directory services, etc) first.
--jeroen
A simple but for most applications strong enough system is given by this Embarcadero's demo:
https://edn.embarcadero.com/article/28325