How disable encrypting password in devise?
DISCLAIMER: While it certainly is not generally wise to store passwords unencrypted, there could exist cases in which the developer would want to do this. Hopefully the developer is conscientious enough to make sure that in making this generally poor security decision for their app, they are not endangering personal and or identifying info of their users. You might imagine a case where the app's only logged information is user interaction with the system as in some kind of study of user interaction.
tl;dr One can disable encryption in devise by creating a custom encryptor
and just having it return the password directly.
I agree with Shingara. You should never store people's passwords in an manner that's recoverable devise stores passwords hashed (not encrypted), they're both unreadable formats, but the difference is that you can't reverse the hashing.
If you're wondering why, this is so that if your site or database gets compromised, the hackers won't be able to steal your users passwords (users have a bad habit of using the same password on almost every site). You don't want to look silly by not hashing passwords, and you've no excuse since it's provided free for you with devise.
The only thing you need to be able to do with a password is authorize a user, which can still be done with a hashed password. You never need to tell users their password if they forget it, instead reset their password to something new (devise supports this too).
Related
If you have an ASP.NET MVC 5 site configured without email confirmation, how can a password reset be performed by an administrator?
I can write a console app which resets the password in the database, but that seems inefficient. Also, the old aspnet_Membership_ResetPassword sproc has no counterpart in the new identity system.
I'm not sure I understand what you're trying to achieve. You still have to get the password to the user somehow, so will you be emailing them a generated password instead of the standard "follow a link in a email to a page that lets you pick a new password" approach?
Also, are you talking about specifically resetting one user's password or resetting all user passwords. If the latter, then a console app is the way to go. If the former, you can simply add a view to some backend that's only accessible to admins that let's them perform this function for a specific user.
As far as generating some random password goes, you're on your own there, but a simple web search should turn up plenty of methods to choose from.
Word to the wise, though, the email confirmation approach is standard for a reason. It provides a relatively secure way to allow a user to regain access to their account when they can't remember their password. It's most important feature, though, is that it forces the user to actually change their password, whereas with a provided password, random or not, users will actually use that password, rather than take the time to manually change it after logging in - especially with password managers these days. That means if you sent that password via email, or wrote it on a sticky or whatever, you now have a huge gaping security hole.
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 using Devise with the Token Authenticatable module. If I look at the data stored in the database, I see that even though the password is encrypted, the access token is not.
Isn't this a major security concern, since if a hacker ever got ahold of the database info, they would have the raw, completely functional access token, comparable to storing an unhashed password?
Security and convenience usually go on opposites sides. It is less secure, but there are ways to mitigate this (reducing convenience, of course). You could expire the token often (using expire_auth_token_on_timeout or periodically reset all tokens.
If your DB is compromised, you have bigger problems! Passwords are usually shared between services by users, so a leaked password is, by far, worst than a leaked auth_token.
Why are they not encrypted?
Passwords are stored in the user's mind, auth_tokens are generated and they will have to be stored somewhere (client-side) in order to be submitted and compared with the encrypted auth_token. A new token will have to be generated every time the user signs in with their "normal" credentials.
Performance might be an issue too. BCrypt is slow and doing this comparison on every request might present an issue.
I couldn't find a "official" answer in the documentation or by one of the developers, so the answer provided is based on my experience and opinion.
In my game app, running from iPhone/iPad to a central server that I control via TCP, I need to send login information.
What I currently do is send a LOGIN opcode with ascii bytes for login and password in the clear. I don't want to send user's passwords in the clear - they could be on a wifi connection for example.
How can I handle encryption of this? Here are my requirements:
I don't want to use a 3rd party lib, I will if absolutely necessary. If necessary it has to be BSD license or similar
What's the impact of me answering "yes" on "does your App have cryptography in it" to the App store
I want this app to be available in every country
Is it acceptable to, locally on the device, hash the password, and send that cached value only? The user's account could be compromised by the hash being stolen, but the password wouldn't be lost (and I wouldn't be storing their passwords)..
I can't have some kind of OAuth out-of-the-app setup system done as I've experienced before, it's too invasive
I'm sort of at a loss here. I appreciate any good help here as this is one of the last 3 things I need to address before ending almost a year of development.. (so this isn't theoretical or premature optimizing! it has grown in to an actual issue..)
First, the obligatory: "Don't invent your own password scheme. If you aren't an expert, you will do it wrong. If you are an expert, you will do it wrong in a creative way that is horribly broken but which brokenness will be invisible until your scheme is in use by thousands"
Next, be clear about what you want to protect, and why. You mention plaintext user passwords being bad for some reason. Are you concerned that a password the user uses in a bunch of places will be leaked by your application, compromising the user's other accounts, or are you more concerned that the attacker will be able to gain access to your user's account?
My concern with what I read in the subtext of your hashing idea is that the hash that the client sends will never change (unless the password changes). This makes it a plaintext-equivalent for authentication (the attacker need only steal the hash; they can then authenticate without knowing the password). It also makes the password a little more vulnerable to brute-force attacks by someone who can see the hash.
I get the impression that you want to avoid encryption for concerns that it will limit the availability of your application. I can understand that reason.
Let's assume that a cryptographically secure hash isn't cryptography (and I don't know if it is or not, but it isn't in terms of U.S. export restrictions as far as I have read). My suggestion would be a very simple challenge-response protocol to use to verify that the user has the password (I recommend you look up "challenge-response protocol" online).
One caveat here is that I don't address getting the password to the server in the first place; just the server verifying that the user has the correct password for the account. Think of this as a general idea of how you might prevent things like replay attacks, and make life more difficult for attackers that can see the data stream:
Client: "I wish to authenticate as John Smith"
Server: "Okay 'John Smith'-claiming-person, take the current date and time (2011-09-09#12:04:33AM) and a random number I just thought up: 4bazillion, and hash them with your password. Let me know what you got."
Client:
prompts user for password
hashes
Says: "I got: gaAGRtcq4qt22332."
Server:
takes date and time and random number and hashes with password
compares data from client with calculated data
If there is a match:
Says: "Okay, you're in."
Otherwise:
Says: "Go pound sand."
TLS/SSL. Just use it. It is built into iOS.
As for encryption, yes, you will need to claim you use encryption, which will require you to get an (easy) online registration certificate from the government.
Authenticate with your service over HTTPs. You will not need to use any third party libraries. You can implement this as either a post or a get.
Here is a list of security issues that my authentication system has to address (I know there are already plugins for this, I want to create my own -- I'm just like that! ((especially since I want to learn how to do it)).
using rails form forgery protection
storing a guid as the auth_token in the cookie, not the user id. Have this token expire every x time, and regenerate a new one.
store failed_login attempts, and lock the account
store encrypted passwords in the db, with each user having their own salt
Is there anything else that comes to mind? I'm looking over authlogic right now to see what else they may be doing.
Simply don't.
You are re-inventing this wheel and there's not serious reason why you should waste your valuable time on it.
Check out Ruby Toolbox for some ideas. I personally love Devise, so make sure to check that out. With Devise you have all your bases covered.