We are using Amplify with AWS Cognito, using SRP.
From our understanding of SRP, passwords should not be sent in plain text over the network.
When the user is required to change their password on login, we use the Auth.completeNewPassword method. Looking at the request, the password is clearly sent in plain text.
Why is this?
This is because even in SRP you need to send the password at least once to the server.
When you sign up or change your password you send two values to the server: username and password. The server generates a new salt for that username and calculates a value called verifier using (among others) username, password and salt. Then it stores the following information: username, salt and verifier.
From now on you no longer need password to be sent over the wire.
Related
I am using a simple membership Provider and I want to retrieve a password to resend the login credentials to a user.
For this I have set enablePasswordRetrieval=true also requireQuestionAndAnswer=false. However, it gives an error on Getpassword(), says method is not supported.
SimpleMembership does not directly support retrieving the password. Instead it provides a method for getting a token to send to the user so they can reset their password. Here is an article that describes how to add password reset to your application.
The password is stored in the database encrypted using a one-way hash algorithm so there is no way to decrypt it and present it to the user.
I have a simple webapp which users login to access to a third party API that also require their personal credential in plain text username and password (no OAuth or anything). What's a proper, safe-ish, and straightforward way to store these third-party passwords so I can decrypt them to plain text when needed and minimise leakage of these passwords?
I'm thinking of just hardcoding GPG keys in to encrypt in webapp for storage and decrypt from another machine behind firewall when needed.
I don't think this is a GPG-specific problem. You could think of a scheme like the following (no need for public key crypto):
Generate a random password to encrypt the plaintext credentials you want to protect
Derive a key to protect this random password from the user's password
Encrypt the password from step 1 with the password from step 2
Now you can access the protected credentials after the user has logged in (since you know the password the user entered). When the user changes his password, you only have to re-encrypt the key from step 1 (in case you use this key in multiple places; so you can't miss one).
For step 2, you should use some (slow) key derivation function like PBKDF2. This makes sure that in case of a security breach, a simple dictionary attack on the encrypted credentials is not possible.
I'm trying to set a cookie so that user can be automatically logged in.
I do not want to query DB for session string when authenticating cookies (basically I need to do that whenever most of my APIs are called, I want to make it faster)
the solution I found is to set a hash in the cookie and try to decrypt it when authenticating, if decryption is successful then log user in.
I am wondering what hashing method should I use? Do I just use a constant salt in my program and hash the userName with that salt, store the hashed userName and original userName in cookie, and try to match userName with decrypted hash upon authentication?
Since I am not familiar with hashing functions, can anyone kindly provide some suggestions on how should I do it in Java?
I recommend you to use an unique token key generated for each session. For example, if a client once logged in from a computer, this token will be valid until the password is changed. Expiring a cookie is not completely secure...
You can also use session variable for a simple authentication. Once you set a session variable for an user, every time this user sends a request with this session id; your session variable will be reached for just this session id. Most of the platforms can also use DB for storing these variables for you.
Two approaches:
1) Create your own authentication framework. In this case I recommend to put in a cookie an encrypted value of a username (I strongly not recommend to use hashing; also please do not put the user password value). For encryption please use AES-256 encryption with BouncyCastle:
256bit AES/CBC/PKCS5Padding with Bouncy Castle
If your framework success to decrypt the cookie – the user is authenticated. If your framework cannot decrypt the cookie or the user is not exist - the user is not authenticated.
2) Please consider to use the Spring Security framework:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html
It is the great framework and solves a lot of authentication / authorization problems.
Your problem is solved by the “RememberMe” feature:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#ns-remember-me
Best regards,
Michael
I don't come from Java background, but your hash key should never be something exposed.
For example:- In your case UserName is key and one of the fellow developers who knows what mechanism you are using can break it down because name is something very common and known.
Don't know what the best way is but I have used UserID(GUID) which is not visible in UI.
I am making a program like yelp. Some people have some accounts. So I got to send the password to the web.
Should I encrypt the password before sending it?
After that what would be the standard password policy others used?
Should the encrypted password be the one stored on the mySQL serve? In other word, there is absolutely no need for decryption?
Basically it's like What encryption procedure I must use to send encrypted 'email' and 'password' values over the HTTP protocoll? but for objective-c
After the user logged in, my program need to tell the server that the user is authenticated already. Does my program need to keep sending password?
There are more than one architecture you can implement, and you have to choose considering many factors, like performance, how many users, server architecture...
Basically, you must use https and not http, store hashed password (MD5, SHA, ecc.) and always check if hashed password is equal to stored hashed password.
You can implement also a "session" using token (you have to create a kind of API server side and then use it on client side) or pass username and password in each call to web service (web service must verify credentials every time is called).
Another "fast" (it's not so fast anyway) solution is to implement (both server-client) a standard protocol like (it's my favorite) oAuth 2. It's used by twitter and Facebook, you can learn more here: http://oauth.net/2/
You might be looking for Base64 encoding:
http://cocoawithlove.com/2009/06/base64-encoding-options-on-mac-and.html
If I understand correctly, the biggest problem with sending a password via email is that it requires the password to be stored in clear text in the database. If the DB is compromised, the attackers will gain access to all accounts.
Is there a workaround for this problem?
How can one make sending a user their password via email as safe as possible?
The simple answer is: don't. If you think your database is insecure, an email is far, far less.
If you mean that you want to send them their password when they register, then you could do that before you store it in the database.
If you mean after they have registered, the only option is to store in plaintext (again, don't do this) or make a new, random password and send them that. It is impossible to get their password from the hash, which is why it makes the password storage safer. The best option is to generate a new (temporary) password you send them, or a token giving them access to a password change system.
You may want to consider a good hashing algorithm like BCrypt that includes a salt.
I don't know if my suggestion is feasible for your scenario, but you should better keep the data hashed or encrypted and send password reset links instead of plain-text passwords.
The moment the password is in cleartext in the email, it is inherently insecure.
As such, there is no safe way to send a password in cleartext safely.
You should not be storing passwords in cleartext in your database - you should be using salted hashes. When the user enters their password, you hash it with the salt and compare to the stored hash.
When people forget their password, instead of sending passwords by email, you should send reset links backed up by expiring tokens. These would generate a temporary new password (that would expire within minutes).
You should be hashing all passwords in your database.
sha1($_POST['password'].$salt.$username);
In the case of a lost password
A user requests a password reset link, which contains a hash generated in the "user_meta" table. When the user recieves this link, the hash is compared to that in the database, and the user will be able to UPDATE their current password with a new password.
The PTXT of the password is never reveiled.
You only compare hashes.
Yes, there is a common workaround.
Assuming that you have your users in your database.
You send the "password reset link" containing some "key" information, like a guid. An example link is a form:
http://your.site.com/setpassword?id=5b070092-4be8-4f4d-9952-1b915837d10f
In your database you store the mapping between sent guids and emails.
When someone opens your link, you check your database and you can find out who asks for the page - because any valid guid maps to an email. You can then safely let the user change his/her password assuming their email is not compromised.
When it's about to store the password, you never store it in plain text, you always hash passwords, using additional random salt to make the dictionary attack more difficult when someone breaks into your database.
There is a workaround which is less secure than a password reset but works if it is a requirement that users are sent a password, not a reset link.
What you do is you generate a new password that contains sufficient randomness to be very hard to guess, but is also formatted in a way that it is easy for them to remember and read out (say over the phone).
Something like: xyz-xyz-xyz-nnnn where xyz is an easy-to-spell but uncommon word and nnnn is a four digit number.
Then set it up so that this is a temporary password that needs to be changed on first login.
Set the password using the same logic you would use to set a normal password, so that it is correctly salted and hashed, and then send the password plaintext via email, like so.
Dear FirstName LastName,
You requested we reset your password.
Your new password is:
insipid-mirth-nonplus-9174
You will be able to log into the system once using this password, then you will need to enter a new password.
Important Caveats
This system has some serious vulnerabilities which make it unsuitable for websites where data security is crucial. There are more than these, but these are the ones I know/can think of:
Unlike systems which use a password reset link, this system could be used to lock someone out of the system (assuming you use it as is) unless you either require someone to fill out identifiable information before issuing the password reset, or send a "are you sure you want to reset your password?" email first. This would entail them clicking on a link with a GUID that goes to the server; at that point they may as well be sent to the password reset form anyway.
Since the password is being sent plain text via email, there is a danger it can be intercepted and the password can be used. Although to be fair this is not that much different than the risk of sending a password reset link.
If you ignore the risks in step #1 and you don't use a sufficiently random way of generating passwords (say you use a word list of fewer than 1000 items), someone who has hacked into your server will be able to retrieve the salted password hash and then write an algorithm that generates all possible passwords and checks them against the hashed password. Not as much of a problem if you use a cryptographically complex hashing algorithm.
If you want to send password to user via Email in cleartext and want to store those password into database as hash or any other format . It will be possible.......
Just you will have to follow some simple way....
1 .you will have to take those password as variable which will send from user.
2. When you store database then just convert it as you wishes format.
3. But when you send those to user by mail , That time just sent those variable password...
I think it will be helpful to build your concept about WAY.......