I have a postgres database running at heroku. In the database I store passwords using bcrypt. The app is a Ruby on Rails 3 app using custom authorization. The authorization is using the rails method has_secure_password for the passwords.
I have planned to move my app to a VPS instead.
Will all my users passwords still be working after moving the database? I'm asking this because I'm not sure how the passwords are salted. Is the method used to crypt the passwords not tied to the database server in any way?
Source - bcrypt-ruby
"Hash algorithms take a chunk of data (e.g., your user‘s password) and
create a "digital fingerprint," or hash, of it. Because this process
is not reversible, there‘s no way to go from the hash back to the
password."
Assuming your storing a password hash and salt as a string then you will be able to store this in any data store. Take a look in db/schema and you will probably find that you are doing this.
Related
I have ruby app with mysql database which has password stored.I don't know ruby but from internet what i found is that ruby stores password in bicrypt format.
I created one user with password : Password123.
What i printed in console was its encrypted password.
Tasks:
Now i am creating a django app which needs to be connected to same database.I need to verify password from same database.That is i used bicrypt algorithm in django dummy app and created user with same password : Password123.
But encrypted text from ruby app and django app are different.It needs to be same for verification from django app.
How to do this? Why bicrypt output of both language different.
I am going to assume you mean bcrypt. I don't know what bicrypt is. The 'encrypted' password is probably salted to protect against rainbow attacks, which is why they have different 'encrypted' values.
Why do you need the 'encrypted' password to be the same on both systems? Does using 'Password123' on either system not work?
I'm beginner with Rails 5, i would appreciate your help.
I have an user model, where obviously save a password for the user for a possible login.
The thing is i want to set the password automatically based on a text_field called identification_number.
Everything I've read is about doing it with Devise gem, but I'm not using it and also don't want to.
Once again, thanks for your help.
The password field is just another string field called :identification_number for your case.
But, saving password in the DB as plain strings is highly unrecommended.
There are a lot of security issues if you save the passwords as plain strings on your database.
Some of them are that:
You have full access on the passwords of your users
If someone, somehow manages to access your database they will also have full access to the passwords of your users.
In order to avoid these issues, most of the applications save the password strings as encrypted strings with some kind of salt for enhanced entropy.
With a quick google search I found some relevant blog posts that can help you build the password encryption from scratch, such as:
Without using a gem:
https://www.sitepoint.com/rails-userpassword-authentication-from-scratch-part-i/
Using some gems:
http://railscasts.com/episodes/250-authentication-from-scratch?view=asciicast
Apart from that, the password is not an identification_number. I would not use that name. The password is not used to identify the user. The id is most of the time the identification number. Better just call it :password. Also, it does not need to be a text field, it shouldn't be that long.
You can use bcrypt gem for implementing the secure password.
The bcrypt ruby gem provides you with has_secure_password method. The has_secure_password method encrypts passwords by hashing and salting the passwords and generate ‘password_digest’.
you can refer this link for more info
I am using rails active admin gem and BCrypt Gem. Now I want to decrypt all users password.How can I do this?
Thanks your support!!
You can't, because bcrypt is a password hashing function, not an encryption.
That is the whole point of using bcrypt.
As I can understand from your comments you want to migrate an existing app in PHP to Rails.
You cannot decrypt the password and get the plain text.
So you need to first find out the encryption mechanism used in the PHP app. If you can't find that out from your codebase then you can follow these steps:
Create a user from your PHP app. Set the password as test.
Get the encrypted password from the database.
Go to BCrypt Calculator and check if test matches the encrypted password.
If it matches then your PHP app is using BCrypt and moving over to Rails using BCrypt will be fine.
I'm trying to migrate a ruby on rails app to django, and got stuck with the fact that the RoR app is encrypting the user passwords in 2 feilds, crypted_password and password_salt, in addition the persistence_toke, so is there any play around to replace this with just a simple md5 hashed passwords without resetting the passwords of all users?
You need the password in plain text to store it hashed (with MD5 or any other algorithm). That said: You would need to restore the user's password from the current bcrypted version. And to avoid the possibility of a decryption is exactly the reason why bcrypt exists.
Therefore that answer is: No, you cannot do that without your user's help.
Btw MD5 is considered unsecure. You should try hard to get the bcrypt version working with Django.
I want to store some keys in an encrypted form in database in a secured fashion. At the same time I need to use the non-encrypted(original) form of the keys somewhere in my code. I planned to use PBKDF2 for password hashing PBKDF2. Is it possible to decrypt the key stored in the database in an encrypted form using PBKDF2. Or Is there any simple and secure procedures available?
Passwords and secret keys are usually stored in their hashed form. That means they are processed through a hash function before being saved to the database. A good hash function such as bcrypt has the following properties:
it produces the same output for the same input
it produces very different output for different inputs
its output is not distinguishable from random
it is not reversible
The last property has a very important security implication: when someone gets access to the database, they cannot recover the original keys because the hash function is not reversible, especially when the hash is salted to prevent attackers from using rainbow tables.
That means if you want to recover the keys later on, you have to save them in encrypted (not hashed) form. An encryption function has similar properties like a hash function, with the key difference that it is in fact reversible. For this decryption step you need a key, which needs to be stored somewhere.
You could store the the key in your application config but that would mean that if someone gains access to your server, they would be able to retrieve the encryption key and decrypt all the stored keys.
I suggest an alternative approach, which will users allow to retrieve only their own stored keys. It is based on the idea that the keys are encrypted with a user-specific password that only the user knows. Whenever you need to perform an action that needs to store or retrieve the keys, the user is prompted for their password. This way, neither yourself nor an attacker will be able to retrieve them, but your program can access them if the user allows it by entering his password.
Store a conventionally hashed user password in the database e.g. using bcrypt
Allow users to store additional password with the following procedure:
Prompt for user password and keys to store
Hash password and compare with database to authenticate
Generate salt for each entered key
Use user-entered password and salt to encrypt keys to store e.g. with AES encryption
Store salt and encrypted keys in database
To retrieve the stored keys in an action requiring them in plain text form:
Prompt for user password
Hash password and compare with database to authenticate
Retrieve encrypted keys and salt from the database
Decrypt stored keys using user password and salt
Be careful to remove user submitted passwords from the application log ;-)
Passwords are never stored in a database in any way that people can decrypt them afterwards. There is no guarantee that someone will not hack your database tables and steal everything that you have stored.
If you store an encrypted (hashed) password for each user, even if your database is hacked, it will take those who stole your decrypted passwords a LOT of time to find out the actual passwords. They can always use your same encryption and compare the resulting hash of common passwords. For example, they can encrypt "MyPassword123" and then compare that hashed password to every password in your database. Weak passwords can still be guessed using this pattern.
Therefore, even non-decryptable passwords have their weaknesses, but if you allow someone to decrypt what you store, then basically it's extremely easy for them to get every single one of your user's passwords. Very bad practice. Some of the biggest and most "secure" companies have had their stored Password Hashes stolen, so you cannot assume you will not be a victim.
I had encountered this same problem with bcrypt using Ruby where it works for user validation since it compares the difference between a user entered clear text and the hashed password and the hashed password never decrypts to clear text. One of the gems I have found that may solve your problem is encryptor, which encrypts using several different keys. So what you can do is to keep your password in the database, while keeping the keys securely in another location (a file in storage).
More information can be found in the rubygems page.
More recent answers to this question:
If you're on Rails <7, use Lockbox
If you're on Rails >=7, encryption is now built in to ActiveRecord