I'm trying to figure out a way to store user-generated text securely in a database (so that only the user is the one who can access his/her stored text). I could have Rails encrypt and decrypt the user's text entries using the user's password as the key, but if the user ever forgot their password there would be no way to ever decrypt their previous content/text (since the Rails app uses BCrypt to store only a hash of the password).
Does anyone know how that could be done? It looks like Dropbox does something like it: "All files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password." (http://www.dropbox.com/help/27) Yet they allow you to reset your password and I'm assuming they don't store your plain text password anywhere.
What am I missing? Any suggestions would be greatly appreciated. Thanks!
Logic dictates that are only two options:
You encrypt using a key known to the server (user's key hash or some other identifier). Intruders can potentially read all the encrypted data, but the user can never lose the encryption token because it is on your server.
You encrypt the data using a key known to the user only (e.g. his password). Then intruders will not be able to read encrypted data, but if the user loses his key, the data is as good as a pile of random bits.
It's clear that Dropbox has chosen (1) from the fact that they allow to reset your password.
Build on Gintautas' Option 1 with a two-prong encryption plan:
Apply option 1, with a key that is known to the server, and
Store the database on disk in an encrypted format with a key that is known only to the server. E.g., in an encrypted volume. When the server starts up, the key must be manually entered in order to access the database.
This "static security" provided by part 2 protects against an intruder in the system gaining access to the database files. Maybe not 100% the exact security you're after, but getting closer.
Related
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
I am creating an app and a website for a project I've got going, but I'm not sure what I should do about login. This is not a "I'm a noob and I want an app with login"-question. I am somewhat experienced with both web-, database- and app-development, but I've never actually touched the subject of security before other than by application templates.
What I'm imagining is a 'simple' login-system like Skype, Facebook, NetFlix, really any app that you are able to log in to, which also has a website to log in to.
A part of my question is towards the security of the process. My initial thought is that a password in clean text should never be sent over internet, which makes me believe that the passwords should be hashed/encrypted on the phone, as well on the website, when logging in. I've done some small-time hashing/encrypting before, but just by using sha1 and md5 to "convert" the text. What's the proper way to do this? With my current knowledge, I assume that if I'm using md5 to encrypt a password, anyone could decrypt it with md5 too, but that I could use a SALT(?) or some form for altering key. Is that how the "big boys" are doing it, or is there a secret passage I don't know of?
Now onto the real question.. How should I store a login securely?
What I've tried: When making a "test-project" in Xcode for this, I simply created a class User with a field for username. When "logging in" by entering a username and password, I simply sent a POST-method HTTP-request to my .php-page, which simply performed a SELECT * FROM User WHERE Username = '$_POST['username']' AND Password = '$_POST['password']'; If the database returned one row, then the password was correct, and the page could print out the user in JSON or whatever. When the device got the successful login, I converted the user-object in the app, now containing the username (and potentially UserID, E-mail, Address etc.) to NSData*, and using NSKeyedArchiver and NSKeyedUnarchiver to save and load the user, never to authenticate again. If the user clicks "Log out", I wipe this 'archive'. This works, but I sense that it's not a particularly secure way of doing it. If so, why exactly is that?
(Our back-end is currently Google's App Engine(java), which has support for OAuth. Some are recommending this, but we can't find any proper documentation that makes sense for our plan with custom users)
Password Transmission
The easy way to secure this is to just send passwords over SSL. If you set up an SSL certificate and do all your authentication over https, all the back-and-forth communication is encrypted by the transport layer. Note - md5 is not an encryption algorithm, it's a weak hashing algorithm - don't use it for security.
Storing Logins
Your passwords should be stored in the database as a salted hash (random salt, with a collision-resistant hash function such as SHA256). Don't store the plaintext version of the password anywhere. If you're using PHP on the server side, you can use the new password_hash() function or crypt() to generate and compare your salted hashes.
If you're communicating securely over SSL, you should be able to just use the session capabilities of your web server to keep track of logins (e.g., $_SESSION['user_id'] = ...).
If you want to securely store your username/email/address, or anything else for that matter, the built-in keychain is the only Apple-happy way to go.
Have a look at SSKeychain (or PDKeychain or UICKeychain) and extend it to include each property you'd like to store. Generally it's used to store username and password combinations, but can be extended to store arbitrary data safely.
As for passing secure data to your server, do it over HTTPS.
I can provide examples if you'd like.
Another option is to add some sort of OAuth or XAuth login process.
That way, you are not storing any passwords, but only so called "Tokens". The tokens expire, and can be revoked.
Not storing the username and password at all is the best way to secure them.
Alex
I'm building an application with Rails and will be pulling timesheets from Harvest, a timetracking app. I'm using an API wrapper called harvested. To be able to interface with their API, I need to provide a subdomain, username and password.
Right now, I'm just storing the passwords as plain strings and have not done any encryption. Would like to encrypt them before storing in the DB. If I encrypt the passwords before storing, can I still use the encrypted password for authenticating with the Harvester API?
OAuth exists for this very reason. Storing plaintext is obviously a bad idea, but storing something encrypted that you then decrypt is ALSO a bad idea.
Modern password flows use one-way encryption: encrypting the password and then comparing it an already encrypted value in the database. This allows use of algorithms that can encrypt easily but are essentially impossible to decrypt. Using an algorithm that allows your application to easily decrypt database fields will also allow an attacker to do the same.
With a one-way flow (encryption only), even if a user gets ahold of your encrypted passwords, they are unusable since anything entered in the password box will be passed through the encryption again before testing for validity.
TL;DR
Use OAuth as someone else pointed out: https://github.com/harvesthq/api/blob/master/Authentication/OAuth%202.0.md
I need to decrypt the password to send in email. Can anyone please guide me that how I can decrypt the "Spring Security" password in grails?
Thanks
Smac
Passwords aren't encrypted, implying that they can be decrypted, they're hashed. Hashing takes various inputs and generates a fixed-length output, so the process is lossy since a large original input cannot be stored completely within a small hash output.
But that's ok for passwords. Rather than decrypting (or "de-hashing") the stored password to see if a login attempt is valid, you hash the password from the login page and compare it to the stored hash value. These two don't have to be the same, and for example when using Bcrypt they won't be the same value, but the hash algorithm implementation will have logic to determine if two hashes are equivalent.
If you store passwords in a way that the original value can be retrieved, you might as well store them in cleartext. But that's crazy since then anyone with access to that table can see them.
As was mentioned in the comments, never send cleartext passwords by email. Instead configure a workflow where your users can reset their password. The http://grails.org/plugin/spring-security-ui plugin has this as a feature. If you don't want to use the whole plugin, feel free to steal the code for this feature. Basically the workflow is that a user requests a reset email for their username. Only ask for username, but not their email; use the one you already have. Generate a unique token and store it, and use it in the link in the email. When the user clicks the link you can validate the token and know that it wasn't just any arbitrary request from a hacker, but that it's from the user since you use their email address to verify their identity.
1) You should be using one way hashing algorithm for encrypting password Which can't be decrypted back. (Otherwise, its security threat for the application)
2) Text password should never be sent in emails. Infact, you should use workflow like sending the reset/forgot password link in the email.(The links can have UUId appended as a parameter for any new reset/forgot password request which is enough to identify).
I want to create a multi-user application, but I don't know how to save and read encrypted passwords.
procedure SavePass(Password: WideString);
var
Pass: TIniFile;
begin
Pass := TIniFile.Create(ChangeFileExt(Application.ExeName, '.PASS'));
Pass.WriteString('Users', 'USERNAME', Password);
Pass.Free;
The passwords must be stored on the computer.
This works but it's stupid to save passwords using this.
Hashing passwords would be also good.
If the connecting software accepts hashed passwords, it's not going to stop people who steal the hashed passwords from connecting. All it will do is hide what the real password is.
Furthermore, if the software that you're connecting to does not accept hashed passwords (database, website, ...), you're going to have to store your password in such a way that you can get it back to its original state. A hashed version is not going to help you there.
If you want to scramble your storage so that humans cannot read the file, you could use Windows.EncryptFile() and Windows.DecryptFile(). In newer Delphi's that's neatly wrapped into IoUtils.TFile.Encrypt() and IoUtils.TFile.Decrypt.
If you really want to stop others from reading the cleartext version of your password, you're going to have to use some encryption with a key. Where do you store that key then?That would defeat the whole purpose of storing a password in the first place. It's better to prevent access by other users by using user privileges to the file system for example, because anything you or your software can do, a "hacker" can do if he has the same privileges.
My suggestion is to not use passwords in your application at all, unless you really need to. The user experience of having yet another password to enter & remember is usually not needed.
What I do for my applications is default to using the domain and user name of the current user as the identification. The user has already logged on with a password, or more secure system if they want it. Only by logging on can they be that current user. My server then accepts that as their identification.
Variations on this include optionally passing the machine name too, so that the same user is treated differently on different computers (when they need to use more than once computer at once). And of course you can still allow a normal password if you want to.
You should store hashed passwords. For example you could use one of the SHA algorithms from the Delphi Cryptography Package. When you check passwords hash the password that the user supplies and compare against that saved in the file.
Have you considered using Windows security rather than attempting to roll your own?
As an aside, you are liable to encounter problems writing to your program directory if your program resides under the program files directory and UAC is in use.
There are hash and encryption routines in Lockbox. You should hash the password concatenated with a random 'salt' and store the salt and hash together. To make it harder for people to brute-force the hash - trying all likely passwords until the right one is found - you should iterate the hash. When the user subsequently enters their password to login take the salt from your store and hash it with their entered password, and iterate, and test the result against the hash you have stored. If they are the same they have given the correct password.
As long as you can, don't store password, but hash them properly (use a salt, repeat hash n times, etc.) because rainbow table attacks are feasible and work well against poor chosen passwords and too simple hashing.
If possible, take advantage of "integrated security". Use Windows authentication to avoid storing passwords.
If you really need to store a master password or the like, use Windows APIs like CryptProtectData to protect them locally.
I think its best to keep user-specific settings in the Registry under HKEY_CURRENT_USER. That will keep their settings all together and separate from other users' settings.
You'll automatically read the correct user's settings when you read from this area of the Registry, and you should store your password there as well. Yes, do encrypt it as David recommends. The Registry is easy for anyone to read using RegEdit.
Here's an article on how you can write to and read from the registry.