After saving the user's data in my Firestore database, the password is not hidden (I don't need to encrypt it) just to hide it for example:
email: xx#gmail.com password:*******
the password is not hidden
The password field in your document is a regular field of type String. Naming a field "password" doesn't provide any benefits at all. So there is no way you can hide that.
As also #Fogmeister mentioned in his comment, you just should never store the credentials in the way you did, as storing passwords in cleartext is one of the worst security risks you can inflict on your users.
If you are already using authentication, simply omit the addition of the credentials in the database.
Related
I'm using asp.net membership for users accounts, user password is encrypted and stored on to the sql database as a user registers , the problem I'm having it when the user forgets the password I can't get it right when trying to retrieve it from the database, I have no idea how I can reverse the encryption.I'd appreciate the help.
You can't. By default the passwords are saved as a salted SHA1 hash, you can't "decrypt" such a hash.
It would be bad practice to save passwords in a fashion that allows you to view them, no matter which algorithm you would be using for that. Just create some logic to enable a user to reset his or her password, instead of trying to retrieve the original password.
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 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).
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'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.