I want to make my applications password changing process a little more secure so that not just anybody can go on to an account and change their password, so my question is:
Is there a way to compare the password in a Parse database to what is entered in a text field? If the "Old Password" text field does not match the information in the database they will not be able to save their changes unless they get it correct. Is this possible? I know Parse encrypts passwords so I am not sure if this is possible and I have found no evidence in my search.
I don't believe this is possible to do. Even if you try to retrieve the user's password the result is an empty string. A workaround could be to try to log the user in again (in the background), which I think Parse allows you to do, and if the log in is successful..well then the password was right! Let me know if you can achieve what you want with this.
Related
I've got a blacklist of passwords that I don't want Users to be able to select when they're creating their account or changing there password in my Rails app.
I want this to be in a database table rather than a YAML file.
How can I refer/check if the user's submitted password exists in this list? What's a way to do it?
It doesn't feel right that I'd need o create an ActiveRecord Model for it etc.
How can I refer/check if the user's submitted password exists in this list? What's a way to do it?
If you encrypt your user passwords (like I hope you do), it's a little bit challenging to perform this check (in fact, that's exactly one of the purposes of salt encryption passwords).
You will need, for each user in your database, loop each password, encrypt it using your current encryption strategy and match the result with the encrypted string stored in the database for the user. If they do match, it means the user is using one of those passwords.
And that's for already stored passwords.
I don't want Users to be able to select when they're creating their account or changing there password in my Rails app.
This is easier than previous step. When the user is signin up or updating the password, just compare the user-entered unencrypted password with the list you have. If there is a match, return a validation error.
Users in my database have a non-unique display name; the only unique identifier is the UserId.
Normally, I would add a user to a Role using the following:
Roles.AddUserToRole(user.Username, role);
But now I don't have usernames, so I need to re-think all work related to Roles.
One messy option I can think of is to copy the Id of every user into the Username field just to satisfy SimpleMembershipProvider... though I'd rather somehow use extension methods to handle this if it's even remotely advisable and possible to do so... just so I don't have to clutter my Users table with a bogus column.
Any help here would be much appreciated.
Update:
Even if I copy the userId to the username column to get SimpleMembership working, I still need a username to create the user:
WebSecurity.CreateUserAndAccount(model.UserName, model.Password, etc)
So I'm at a loss of what to do, aside from rolling my own Membership.
Update again: I just realized I can pluck my email field and just use the Username column to store unique email addresses. I'm still interested in hearing how else this could be addressed.
You need something unique the user can enter to identify themselves during authentication, whether it is a username they user came up with, an email address, PIN, etc... Having the user remember a number generated as the unique identifier for the UserProfile does not seem like a good user experience. So whatever is used to uniquely identify that user, that is used during the log in process by the user, can be stored in the username column, if you do not want to add any additional columns. From the latest update to the question it looks like email address is being used to identify the user and you could store this in the username column without issue.
Adding columns to the UserProfile is easy to do and I would not shy away from it if it provides a better user experience and security. For example, if you want to capture a display name to display on the web site or in any communications with users you could add an email column and tell SimpleMembership that you want to use that to identify the user by changing a parameter in the WebSecurity.InitializeDatabaseConnection Method. You would change the parameter userNameColumn to be the name of your email column.
yes, either use the Ids as username or if the email is unique as username.
It is not a messy way btw with this situation. I would go with the id, if no one will eversee the userId.
I am trying to implement a multistep form in rails using Devise. I plan on storing the information in session variables to persist from one step to the next. My question is, is it ok to store the password in plain text in a session variable and then clear it once done with the form?
I'm not an expert on security but my intuition told me this is not a good solution though possible.
A better solution is:
In step 1, you create the user actually and save the passwords, email as usual.
In step 2 or more, you update this user's record in db with further input. If anything not satisfied you can even delete this user finally.
This is based on convention and is better than hack.
Absolutely not. If you read the rails guide, there is a specific bullet point about this:
The client can see everything you store in a session, because it is stored in clear-text (actually Base64-encoded, so not encrypted). So, of course, you don’t want to store any secrets here. To prevent session hash tampering, a digest is calculated from the session with a server-side secret and inserted into the end of the cookie.
From http://guides.rubyonrails.org/v3.2.21/security.html#session-storage
Recently I had a client from Singapore try to log in to our web-app using a password that we gave him over the phone.
The password was short and alpha-numeric; no special characters. He couldn't log in after several tries, being very careful to input each character correctly.
We then decided to send him the password over email as a test.
He copy and pasted the password, and successfully logs in.
My theory on why this happened is because he was using a different encoding or international keyboard. Is there some way to prevent this from happening, or some things I can check for as far as encoding goes?
Tell him to send back the way he typed it, and compare it. if it's alpha-numeric, there's no reason it would be different.
(English characters are the same worldwide)
I am coming to the end of my rails project now and I have done everything I wish to do apart from confirm the users account through email before creating it. I already have it to send an email to the user but I want the user to contain a link. It's far too late to add devise now as I already have a users table etc.
I have heard of having a confirmed field in the users table and having it set to false and then true on user confirmation, but I have no idea on how to implement this. Any ideas?
If anyone else has some other solutions or links to tutorials showing how to add such feature then that would be outstanding. The end is so close yet so far.
It's never too late to add devise. If I were you, I'd do exactly this.
But, if I were to implement confirmation functionality myself, this is how I would go about this:
For each user, make a hash (as in MD5 hash). There are many ways: 1) for each user generate its own and store in a dedicated table column; 2) make one out of password salt, user id and (optionally) some static strings; 3) something else.
Send a user an email with a link, which contains his id and that hash.
When someone hits your confirmation url, you extract user id and hash from query string, and compare them with what you have. If they match, then you mark user as confirmed.