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.
Related
I'm using Oracle Rest Data Services (ORDS) to build APIs.
The client requires basic authentication (username and password). This does not seem to be supported by OAUTH2.
Is there another way I can protect the APIs by means of just a username and password?
EDIT:
We are using IIS10 - is it possible to setup basic authentication from an IIS perspective?
Yes you can, but we don't recommend it.
You can create an ORDS user (use the user command), and assign a password and one or more roles.
You can fall back to database user/password auth. That authenticated user session is given a role called 'SQL Developer,' so if your REST API was protected via privilege that was also put into the 'SQL Developer' role, it would get authorized.
We don't recommend this for a few reasons.
One of the biggest is how much slower it is. We have to make an actual database connection to ensure your user/password combo are correct. That takes TIME.
Hence, we point folks to OAuth2, or something higher up the stack like an API Gateway.
Coming later this year, we'll have out-of-the-box support for OpenID. This will add tremendous amounts of flexibility without sacrificing security or performance.
Disclaimer: I work for Oracle and am a product manager for ORDS.
I'm new in LDAP. Perhaps the question may seem strange, but on the internet I have seen different versions. Please, help to understand which way is the correct authentication via LDAP. I have an LDAP-directory where user passwords are stored as hashes. I know two ways to authenticate third-party applications using the LDAP-directory:
Authentication check on the LDAP side. Using the “bind” function the DN and password of user are passed in plain-text. If the bind is successful user authenticate, otherwise doesn't.
Authentication check on the application side. Using the function “bind” we connect to the directory as an admin. We are looking for the right user and get his record. We parse password field, isolating the type of hash algorithm (e.g. {CRYPT}). We make hash of the user-entered password with proper algorithm. If the hashes are the same then the authentication is successful, otherwise not. (That is, the application must maintain an appropriate hash algorithm).
Which option is the most correct? And which way is considered a standard for any-vendor systems which claim support for LDAP-authentication?
You'll want to use Option 1!!!!!
Option 2 has some disadvantages:
You'll need an admin account that can read the passwords to be able to compare them to the one you hashed. That means that the application is able to read the password hashed. I'd consider that a bad idea.
You'll circumvent additional security measurements implemented. The password you are checking might be the right one. But due to other policies the user might be locked and should not be able to login. And failed attempts will not count towards a possible lockout.
The hashing algorithm might change in future to one you haven't implemented yet.
You might be able to circumvent those obstacles but you will need aditional code to implement that. And that effort has already been taken and is readily availabel when you use option 1
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.
The Symfony2 Security documentation is pretty complex and not well documented.
I have a question regarding how to Authenticate a user from database. There is no good example as to how to Authenticate using simple username and password from database table.
My question is, in order to Authenticate should I
1) Implement the UserProviderInterface interface and call function loadUserByUsername
2) If user found return the User Object
3) Check if form submitted password and the User object password match
Is this correct?
Please advise
While I agree it is a little complex, everything you need is documented and not too hard to find with a little research, hopefully the following helps you out:
Check out the FOSUserBundle if you want to store users via Doctrine ORM, MongoDB/CouchDB ODM or Propel.
If you want to entirely build your own user provider follow this guide.
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.