Can anyone point me to how PingFederate can authenticate accounts with salted MD5 hash passwords?
Thanks.
The use case you're after isn't totally clear - but I'm going to assume you are acting as an Identity Provider (IdP) with PingFederate and you have accounts stored in some system / database that have their passwords MD5 hashed (with a salt).
Depending on the version of PingFederate being used you may need a custom IdP Adapter (pre-6.6) or a custom Password Credentials Validator (6.6 and up). The PingFederate SDK has Javadocs that describe the API's required along with sample code. Your custom adapter/PCV will be some Java code that looks up the user's account, MD5-salt-hashes the incoming password and compares that result with the stored account. If it's a match, the custom code will return a status code that indicates so.
You will of course then need your SP connection(s) then configured to use this IdP Adapter / PCV (within the HTML or HTTP Basic auth adapter).
Related
I have an issue when it comes to encrypting user passwords. I have a authorization services with which one can create a user account. Given is an email and a password. As for now I encrypt the user password in the server before persisting it in the database.
However I feel that is somewhat wrong because the password is in plaintext when coming in through a https request. So I actually could log the real passwords of users.
Isn't that a dangerous way to handle user passwords? I think it would be better to encrypt user passwords in the client side code (javascript) before submitting a form (either registration or login). So the password will arrive encrypted already.
Am I right with my concerns?
I encrypt the user password in the server before persisting it in the database.
Please don't. Use slow salted hash if possible (BCrypt, SCrypt, Argon2,..)
If you really cannot use the mentioned functions, than a database native hashing functionality is better than encryption.
https://practice-code.github.io/architecture/how-to-store-passwords-in-a-secure-way/
the password is in plaintext when coming in through a https request
Nope, the https encrypts traffic between the client (browser) and the server.
Yes you can see the password in the browser side before encryption (but the user entered the password, so it looks ok to access its own data) and the server needs to validate the password anyway.
Isn't that a dangerous way to handle user passwords?
Indeed. So maybe it's a good idea to offload the user authentication to already proven services (AWS Cognito, IBM AppID, Azure AD,..) or to social accounts (Google, FB,..)
I think it would be better to encrypt user passwords in the client side code
As already commented, that is not helping at all. Then the encrypted value becomes the password
Nothing is in clear text when using HTTPS, data is encrypted that is the main point of using server certificate !
As an alternative approach usually one stores the password hash in db instead of the password text, so eventually your code uses hash algorithm to generate the password hash and compare it versus one stored in DB, by that even if someone was able to access the database records ,that one is unable to figure out what is the password because all he gets is the hash value
Using Hash in C#
How can I validate a username/password against Azure AD without showing a UI? I have an autonomous processes running (think Windows Service or scheduled task) where the username and password are stored in a configuration table.
Since there is no "user at the wheel" so to speak, we can't use the normal method that shows the Azure login page (https://login.microsoftonline.com/{tenantId}).
1. Just make it work, no changes approach (Not Recommended)
You can try to get a token using Resource Owner Password Credentials Grant. (ROPC might be the least secure among all the different grants supported and brings potential attack risks. Also note that ROPC doesn't work with MFA and has issues with federated authentication users or may not work in those cases at all)
I don't think there is any method/endpoint available to specifically validate the username/password, but the workaround is if either username or password is incorrect, you will get an exception from the token endpoint when using ROPC, otherwise you get back a valid token which means credentials are good.
You can read about how to get a token using ROPC here:
Resource Owner Password Credentials Grant in Azure AD OAuth
2. Suggested Approach, some changes required (Recommended)
This might feel a little inconvenient at beginning, but it will be well worth the effort from a security standpoint. Note that this approach as well as the first one will meet your requirement of not going through normal login page as well.
Since there is no "user at the wheel" so to speak, we can't use the
normal method that shows the Azure login page
(https://login.microsoftonline.com/{tenantId}).
As you mention that the autonomous process is like a Windows Service or Scheduled task, from Azure AD and OAuth 2.0 perspective your process looks like a Daemon service. So instead of using a username/password credentials directly from configuration, which violates security best practices, you should be looking at using Client Credentials Grant. It's strongly advised NOT to collect/manage/store end user credentials (or create old world Service Accounts) directly in your applications.
You can read about it in detail here: OAuth 2.0 Client Credentials Grant with Azure AD.
Also visit this documentation for all Azure AD app types and scenarios, specifically those listed for Daemon apps. Link
To put it very briefly, your process gets represented by a registered application in Azure AD and for credentials part you can use:
a. Client ID + Client Secret Key (provided by Azure AD specifically for your application. you can generate more than one secret keys for different purposes with different expiration etc.). Sample C# code with Client Secret
b. Client ID + Certificate (pass a JWT that you need to create and sign with the certificate you registered as credentials for your application). Sample C# code with Certificate
So I have a web Api that authenticates users by username and password. The clients talking to the API will android phones that have an internal app on it to get / send some data from / too the api.
I have hashed passwords in the database with a salt. The connection between the client and the API will be SSL.
Now on the website (MVC) I log users in by generating a new hash and matching this against the hash in the database.
The some of the android devices will have a config file that locks the app to a specific user. Now I rather not store the password in plain text on the device and would like to encrypt the password.
The question now is what would be the best practise here on comparing the hashed password. I dont think its save to just send the plain password to the API or is it?
It's safe, because you're using SSL.
Basic authentication isn't acceptable for plain-text requests, but since HTTPS encrypts everything, it shouldn't be an issue.
Storing the password is a completely separate concern, as you've noted, and that should be encrypted as well, which it sounds like you'll have Android do for you. The only consideration is that you will have to do a reversible encryption to be able to send up the password itself to your API.
Basically:
(client-side) User enters creds
(client-side) Encrypt creds, store in configuration
(client-side) Read from config, decrypt creds
(client-side) File HTTPS request to API with Basic authentication type, using decrypted creds
(server-side) Hash (one-way encrypt, basically) the password, compare against database
That sounds like exactly what you've got, and I see no problem with it.
That all said, just for what it's worth, I'd be tempted to implement an OAuth 2.0 server for this particular use-case, so you don't have to think about persisting the password at all. That's a pretty big undertaking (sort of--it doesn't take too long with those instructions), and you should evaluate it on a case-by-case basis. But any time I have to worry about API authentication, I generally wind up either going with that, or wishing I had.
I would consider using something like JWT (JSON Web Token, http://jwt.io). You can have a client authenticate against your API, and if they provide the right credentials you can issue a token to them, which they can persist on local storage. They would then provide this token in the header of any API requests that require authentication. You can use OWIN middleware to intercept requests, check/validate the token and let the requests through to your controllers if you consider the token to be valid.
I want to make my ASP.Net site authentication seamless using Ajax call.
So I consider using client side authentication service of microsoft that should be used via HTTPS because it sends username and password in plain-text format.
And the problem is that I can't use SSL in my site.
So I found a way to hash data before passing to web service that is described here
but the problem is there is a salt in DB that should passed to client for creating hashed password (that equals to DB saved password). and this is not safe.
Is there a better way for doing that?
I found a way.
We will use RSA for encrypting username ans password.
in summery I'll have a web service that creates RSA keypair and save it (this key will be regenerated every day to be more secure).
I will have a textbox or hidden field that calls this service and get the public key.
the for encrypt username and password with jCryption library client side and pass this to my authentication service using ajax call.
so the server will decrypt them with private key and the authenticate user.
I found a way.
Check this out: Secure AJAX Authentication without SSL
Just in case you were looking for an ASP.NET version of jCryption for bi-directional communication, which you mentioned you tried, you can find one on GitHub here: jCryptionNET
I have a service (WCF) with which my ASP.NET page will communicate. The WCF service has hashed passwords in its data store (a file actually). The WCF service requires the username and the hashed password on every call.
Nowm the problem I'm encountering is that if I authenticate the user with forms authentication in ASP.NET, a cookie will be saved in the user's computer after the user is authenticated but I would like to save the username and hashed password too so that the user may able to use the WCF service. Where should this information should be saved so that it is safe and secure?
Should I use session variables? If I choose that option that, then should I switch from forms-based authentication and manually authenticate using session variables or use both forms-based autentication for web page access and store the username and hashed password in a session variable? What are the pros and cons of each?
Can you store the username and password (hashed of course) in another cookie? Each time you communicate, grab the cookie and send it along with the username to the WCF service.
On the WCF service end you'll have the username and the hashed username/password combo. If you apply the same hashing you should end up with the same string that you've got stored in the WCF end, if they match the user is valid.
Regards to your edit:
Not sure that there is a much of a distinction between them as you're suggestion. If you use forms authentication a session variable is created and (assuming you're using cookies) a cookie is stored that allows the session variable to be associated with the user. So even if use forms authentication you're still using session variables.
The only question really is if you want to store a hashed version of the password entered by the user in a session/cookie. The pro is that its being stored somewhere and that could potentially pose a security risk.
A completely alternative approach is rather than sending the password and re-authentication upon each request, send an authentication token that doesn't relate to the user's password. Validate this token instead.
The token could be issued upon successful login, and should use the same hashing algorithm as the WCF. Send the username and token as part of the request and validate that it is valid, authorised and still current.
Definitely not on the client side (cookies). Use the cookie to authenticate the user to ASP and for the session ID. This is the ASP.NET default. Than store the username and PW in the session.
Consider using Windows Authentication or other recommended mechanisms, since they will bring more security.
#your edit: I suggest keep using forms authentication along with related controls (or any other preimplemented method in ASP.NET). Reimplementing it on your own would make large effords for no reason - at least if you want to get the same safety as the .NET authentication brings. It really is more than comparing hashed passwords..! Also, use the session, since this is the natural place to store any additional user related data. Again - sessions are easily configured and relatively safe.