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.
Related
I know that the salt we use to encrypt passwords should be :
They are algorithmically generated from some pieces of data associated with the user, for example, the timestamp that the user
created
They are randomly generated and stored in some form
They are plaintext or two-way encrypted along with the user's password record
Due to the first point, when anyone access to db, set his password for another user, he can not login instead of another user.
but when I use BCryptPasswordEncoder I replace my password in password column of another user and I can login by that user.
In my opinion, it is a security problem, because the admin that access to database can login instead of any user and may do some work. and these works is logged by that user not admin user.
If we use userId or userCreationTime or something like that to generate salt and override
PasswordEncoder#match method, the problem is resolved.
If these points are true my question is:
How can I use a custom salt generator in BCryptPasswordEncoder?
Salting is meant to prevent rainbow table attacks against leaked hashed passwords. With good per-user salting, one rainbow table will not work for the entire db, and an attacker needs to generate a rainbow table per user. This, combined with a computationally complex hashing algo, makes impractical to reverse engineer passwords from a leaked hashed password db.
If someone can manipulate the db, however, you are pwnz0r3d. If an admin can modify the db, they can modify user creation time. They can also "swap" user id with the known value.
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 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'm new to web security so I don't want to implement my own. I plan to use SimpleMembership via the VS2012 template for an ASP.NET MVC Internet Application. The problem is that I need to pass the data via a Web API.
I plan to use basic authentication for my Web API, so I just need to pass username/pass in the http headers. I can intercept the message using Thinktecure.IdentityModel. Here's an example that uses ASP.NET Membership:
authConfig.AddBasicAuthentication((userName, password) =>
Membership.ValidateUser(userName, password));
I can replace Membership.ValidateUser with my own bool function. I've successfully queried my custom database with username/password and everything worked fine. However, I'm using the template's user database because I DON'T want to store string (or even encoded) passwords.
I am unclear on how to manually validate the credentials using the SimpleMembership's database. I can grab a UserProfile, but can't figure out how to check the profile's password.
UserProfile user = context.UserProfiles.Find(1);
==OUTPUT==
user
UserId: 1
UserName: "bob"
Do you know how I can check if an inputted password matches that of an existing user?
Thanks for your help!
Why you are not using Membership.ValidateUser? This is not restricted to just ASP.NET Membership assuming you have your [InitializeSimpleMembership] (here) attribute in the correct places or have executed the logic inside it yourself elsewhere, and you have the correct references to WebMatrix etc you can still just call Membership.ValidateUser and it will use SimpleMemberships Validate user.
If you wanted to go to the database yourself, and assuming you are using hashed password etc then this article is probably going to help as you are going to need to hash your inputed password before selecting it out, the rest of which is just writing some EF or (any other db access method) to select from the User table where the username and hashed passwords match. But I can think of no obvious reason to do this as Membership.ValidateUser will do all this for you.
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.