I have a asp.net application which is using form authentication, as this application is going to be online and we are looking for a secret login page by which we can login to any user account with only his username.
Is that possible?
EDIT
Or if there is any way I can read password from sql server aspnet_Users table, If I can convert it into plain text and use a general method to login. That would work for me
You can't "convert" it back. All hash functions are one-way only so there is no way to get original value.
Edit: There are 'rainbow' tables, which is basically dictionary of text-hash mapping. But they won't help you, because passwords are also salted in default Membership implementation.
Related
I'm new to programming, and especially .NET Core. I'm very confused over password verification. My password field in the database is hashed. What is the safe way—and perhaps best practice—in .NET Core to verify the username and password?
Currently, I get the username and password from a binding model on my controller action:
public IActionResult Login([FromBody]LoginModel user)
My approach is to hash the user.password and then, along with the username, query the database to see if the credentials match an existing user. Is this the right way?
Just came across this. The answer is no, this is not the right way. In general it is better to leave security to the experts and use what they come up with.
First, you are only solving the authentication problem, but not the authorization problem. How do you ensure that nobody bypasses the login page and directly uses your app without login?
And secondly, and MD5 hash is no longer be used for authentication. There are many traps like this that you need to avoid.
It's rather straightforward to use the Google Sign-In library on the server side and attain a GoogleIdToken to validate a user's identity. However, I'd like to encrypt per-user data in my database with a secret that's unique to every user. Is there an easy way to do this? If not using Google Sign-in, you can derive keys from a user's password, but that's obviously not possible here.
Well, first of all, you're drawing a parallel to using the user's password to derive an encryption key, but since you're talking about that as an alternative if you weren't using Google Sign-On, that implies your talking about using the password that users would authenticate with. That's a bad idea.
Users need to be able to change their authentication password, and that will be a major hassle for you if you're encrypting with it. It will require you to decrypt everything with the old password and then re-encrypt it with the new one.
So what you need to find is something that you can pull out of the GoogleIdToken that will never change. Email addresses change, so I wouldn't use that. Perhaps the user id, which you can get with GoogleIdToken.getPayload().getSubject() is what you want. Then what you would want to do is derive a key from that. I would look for ways to combine it with other information that the user gives you that really is secret, though.
The information you receive during a Google sign on is intended for authentication purposes. The id token is encoded as a Json Web Token. There is nothing secret in a JWT.
The information is cryptographically signed by the authentication provider, so you can verify the information. This is of no help for deriving secrets, though.
Looks like you'll have to find another way.
There's no way to do this with just Google Sign-In, but you can use Firebase to convert user authentication credentials (with Google or other systems) into storage restricted to access by the user.
You can do this by using Firebase Authentication; you can authenticate your users from your backend, then store the encryption key for the user in User private objects. (Or possibly just store the data you wanted to secure in those objects.)
Then your server can be set up to not have the access rights to read user data unless those users are logged in, although you will still have administrative ability to read all user data.
I am developing an iOS app that is password protected and all the users are stored in a wordpress account that, of course, is password protected as well. Does anybody know the format that wordpress uses to store login information for these accounts, I would assume that it is a MySQL that sends a json? I have only been able to find the database code for the initial admin page but nothing that shows the way these accounts (815 to be exact) would be stored within the site.
The raw data is in the wp_users MySQL table.
The (default) code WordPress to authenticate users in the wp_check_password function. It's possible (though unlikely) that the password is a straight MD5 hash (I assume that check's just for backwards compatibility). Usually, it'll be encrypted using the PHPass library (see here for the WordPress code).
As far as I know, there's no API for checking a password that returns JSON. You'd probably have to write something yourself. This question suggests the wp_authenticate_username_password would be the best way to check the username / password combination on the server.
What would be the most secure method of using cookies to authenticate users in a classic ASP website?
I don't want to use the ASP Session object as the session cookie times out after a while, and I'd like the user to be able to keep their login to the website active between separate browser runnings.
However, I don't want to just create a cookie containing their user ID as that could be easily forged - so what are my options here? I guess some sort of encryption but I don't really know what the standard methods of doing this is.
Your options here are pretty much limited.
Get your users to log back in again; best security approach.
This obviously applies much wider than just ASP.
The best way would be to hash the password... you should be doing this in any case where you store it in database.
The hash is a cryptographic function - when you run a string through it (eg password) you get out a long code. If the input is the same, the output is always the same.
But (this is the important bit) its mathematically virtually impossible to reverse the process - to start with the hashed value and work out the password, other than brute force (someone hashes dictionary, or random strings and looks for output that matches the hash they have).
So when the user sets up account, they put in their desired password, but you hash this, and store that. Similarly in the cookie, after they login you store the hash, not the password, and this has is compared with the hash in the db.
The downside is you can't send a password reminder since you don't know the password - to you'd have to send a password reset link and have a system to do that.
If you're really paranoid you might double hash, eg when they login the password is hashed once and stored in cookie. Its then hashed again and compared with the password in db (which is also double-hashed).
Don't Do It
Maintaining a user login quote "...between separate browser runnings" is not secure. IMHO, when you close the browser a previous login should be gone. Suppose your visitor was using a community pc at a coffee shop.
If you maintain this login the potential for the next community user to open the browser, navigate to your website and "poof" they are automatically logged in as the previous user.
I’m developing a website of a client and they are sending out newsletters to their customers (through the website administration interface)
The newsletters are personal to each of the subscribed recipients/customers.
Each recipient/ customer is also a user with a username/password that enables them to sign in on the website and manage their newsletter subscriptions and participate in the sites community.
This all works like a charm.
Now my client want a “Manage my subscriptions” link in the newsletter email that when pressed automatically signs the recipient/customer in on the website with no need to remember username and password.
This could be easily solved be making a link like this:
http://mysite.com/manage.aspx?user=peter&password=hounddog
Of course information should not be clear text but encrypted in some way.
This however poses a problem since the only way a user can be authenticated on the website if by providing a valid username and password.
In the name of security, passwords are stored as hashed values in the database making it impossible for me to insert the password in the link.
What is the best way to accomplish this without compromising the security?
You will have to compromise your security somewhat, if you want people to be able to login without entering password. Note that even if you had access to the password (as in your example), you would have to embed it in a mail massage which would be transmitted in plaintext.
You can create a Guid associated with each user and message, and append it to the URL, and allow that to login automatically.
You could perhaps isolate the permissions so that a login through a newsletter guid link only allows the user to manage subscriptions, but that a real password-login is still required to participate in the forum. In that case its pretty limited what havoc can be wrecked if someone gets access to a Guid from a mail message.
Could you not insert an encrypted user name bundled with the hash value of the password?
What I mean is, encrypt & encode the user name to always be a particular length or to have a known break character in it then append the passwords hash value. this way, you could break apart the query string easily while still having the user name and password securely encoded. A straight compare of the hash values would be enough, with the unencrypted, decoded user name to allow access.
What about using an encrypted cookie that contains an access token ?
This cookie would be delivered after a successfull authentication by a separate page.
This kind of token can also be part of the URL query string.
Also you might consider using secured https instead of http.