Is there a possibility to enforce re-authentication on important / critical user operation in the application?
In our app, the user can perform some critical operations, where we would like to enforce an re-login / re-authentication, to ensure that the right person ist behind the pc. Even though the user is authenticated via SSO, we need that the user enter his login credentials again. Beside of that we need a different expiration timer for this special operation (shorter then our default token expiration).
I know, keycloak provides a possibility to configure different authentication flows in different clients but i have no idea how to combine different clients in a single session?¿ (and if it is possible at all).
I hope, someone has an idea how we can secure such a kind of this critical operations.
Related
If an application redirects the user to the Keycloak login page, and it sits there for more than the "Login timeout" (default 5 minutes), then when the users enters a username and password, instead of a login, she is greeted by:
You took too long to login. Login process starting from beginning.
To avoid this, one can change "Realm Settings → Tokens → Login timeout" to e.g. 10000 days which is 27 years, which should ensure this never happens in reality.
But before we go ahead and effectively disable this timeout, we'd like to ask: What is the purpose of this timeout? Somebody apparently went to the trouble of implementing it, but what is it protecting against? What are the (security?) consequences of disabling it?
As far as I know, it is mostly used as an additional mechanism to avoid session fixation attacks. For instance, in a company a user goes for a coffee and leaves the computer on, and then the hacker sees the opportunity and manually sets in the Browser URL the
current login session ID (or just copies it). Now if the system is configured in a way that the session ID does not change in-between the pre and the pos login phases. Then after the victim has successfully authenticated, the hacker will be able to use, without having to insert any authentication, the session that the victim is currently on;
The higher the timeout is, the wider will be the window of opportunity for such attacks to happen. Login timeout is just another layer of protection to avoid such issues, as it is session expiration, changing the Session ID between the pre-login and pos-login phase, among others.
More formally one can read in (source).
Initial Login Timeout
This extra protection mechanism tries to force the renewal of the
session ID pre-authentication, avoiding scenarios where a previously
used (or manually set) session ID is reused by the next victim using
the same computer, for example, in session fixation attacks.
And from the OWASP.org
Session Fixation is an attack that permits an attacker to hijack a
valid user session. The attack explores a limitation in the way the
web application manages the session ID, more specifically the
vulnerable web application. When authenticating a user, it doesn’t
assign a new session ID, making it possible to use an existent session
ID. The attack consists of obtaining a valid session ID (e.g. by
connecting to the application), inducing a user to authenticate
himself with that session ID, and then hijacking the user-validated
session by the knowledge of the used session ID. The attacker has to
provide a legitimate Web application session ID and try to make the
victim’s browser use it.
A fairly good explanation on how the session fixation attacks works and how to prevent it here and here.
Now I am not a security expert, but I would say that if you have other preventing mechanisms in place such as change the session ID, you should be fine. However, on the other side of the coin, do you really need that much time to login? And is that much of an annoyance to just refresh again?
Here is how my application should work:
Users can use some functionalities of my application if they have enough chips (token) which they can buy from another application, or they can be granted to them upon some event, whatever.
Users have an attribute associated with them called 'chip', which represents some number. This information should be represented as a claim, probably.
I want Keycloak to do this authorization for me - to check whether user can use the functionality or not. I've come across JavaScript-based policies. It's seems they are able to operate on informations in tokens - like user email etc, but this is not my case where token can contain obsolete information, i.e. when token was generated user had enough chips but since then he spent them.
Maybe token should be refreshed upon spending chips, but in that case, would it be updated with current informations bound to user? Or maybe authorization service can somehow access database during evaluation of a policy? Could this work or are there any elegant solutions to this use case?
Keycloak is not here to check if the user has enough money. Keycloak is here to say if the user is authenticated and if he has the roles for a certain application (admin, user...).
Checking if the user has enough money should be on server-side. For an incoming request, you have to check in the database if the user has enough chips to access the application and if he hasn't you return 403.
Related to Accessing Third Party Apps After Creating A Session Via API Token and to AWS API credentials with OneLogin SAML and MFA
Since AWS assumeRoleWithSAML temporary security credentials are only valid for one hour and we have a few different roles to assume it would be very annoying for the user to enter the username/password everytime he needs to switch the role or get new credentials because of the short validity. It's totally odd to the web base OneLogin usage, where he is logged in once for the whole day or even week (depending on the policy).
I know how to get a session via API. At least this would reduce the times the user needs to enters username/password to two times. One time in the web, one time on the CLI.
But is there any way to use this session token to generate a SAML assertion via API with this session token instead of submitting username/password to the API endpoint?
I don't want so store the users credentials locally for this. And with MFA enabled this wouldn't work in a seamless way.
While being able to generate a SAML assertion for any user (without the need for MFA and a user/pass) seems like a good workaround, this is unfortunately fraught with security perils.
An API that bypasses the usual authentication effectively gives that endpoint the ability to assume any user in AWS. The "assume user" privilege is locked down pretty tightly in OneLogin, and is not the sort of thing that's given out lightly.
Basically, an API to do this seems dangerous from a security perspective. This might be something we'd consider as part of an oAuth flow (or OpenID Connect resource endpoint) but that'll take some more thinking on our part before we'd implement it.
The only compromise solution I can think of that could be implemented today would be to temporarily cache the users' credentials for a longer period of time in your code. This way they could be reused to generate new SAML assertions for a longer period of time, but would effectively be thrown away after (say) eight hours.
This wouldn't allow for MFA on an app policy, but we are building out the ability to request and verify MFA via API (coming soon) so you could implement MFA in your app (independent of any app policy) once this becomes available.
Obviously the ideal solution would be for AWS to let users' configure the session length, but so far they've been unwilling to allow this.
I am researching different Single Sign On options. It seems to me that SAML while is a great solution if we look at 3rd party vendors it is somewhat out of our price range. We are also looking at implementing our own solution... but, some of the services we want to use - just to enable SAML logins they want to charge. If I know all of my user's credentials what is the security risk/downside of just doing an HTTP POST with the credentials to these different services? Some of the SSO providers do this when SAML is not enabled as well.
Using SAML would remove the need for users and Service Providers to deal with password issues like reset, expiry, recovery, rotation etc. completely, aside from managing the synchronization process that now needs to happen between IDP and SPs.
In addition to that there's the the amount of brittle, costly and awkward reverse engineering of SP login webpages that needs to be done and maintained(!) by any IDP that operates a password vaulting system (which is what you describe).
Also, introducing an SSO system allows you to concentrate user authentication efforts and improvements in one place only, making it simpler to introduce strong or second factor authentication for all services at once, without requiring support for that by each SP.
Last but not least: password vaulting systems still involve passwords that are distributed over different systems/SPs and that cannot be (completely) hidden from the user. That makes it hard or impossible to ensure that access to all systems is turned off at once e.g. when a user leaves the organization.
I want to make a simple REST web app, where the user interact with the objects through links in an email. The links have a token that can be used to authenticate a user without a username and password, like the ones that are usually used to reset a password.
What are the best practices for such a login-less, token-based authentication system?
I am by no means a security expert.. but some of the points which come to mind are -
Lifetime - The token should expire after a set period of time. Indefinite access using the token certainly doesn't make sense.
Replay attacks - The mechanism should prevent replay attacks.. which means the token should be valid for not only a set period of time, but also fixed number of calls.. Ideally exactly 1. If this number is not exactly 1, then it opens another can of worms..
Unless, its a feature :( For example, by design, the user is expected to share link with others, and anyone with the link should be able to access the resource in question.
Authorization - Granularity of the access granted by the token. Is it black and white.. or is the token also associated with a fixed set of rights. For example - token X was issued for Read-Only access, vs token Y was issued, for same resource with R/W access.
Administration - User / Admin should be able to see and verify any currently active and issued tokens, and associated information (permissions granted / affected resource etc), and explicitly revoke them, if necessary.
Secure Communication - You should consider security of the medium through which the url with token will be sent to the user. i.e. in your scenario, do the users receive emails over secure channel (TLS / SSL)? Should the email itself be protected with DRM?
Man in the Middle / Leaks - Similarly, even though you are providing the url in email, and the user is not logging on using user name and password over SSL, the resource should still be accessed using the url with token over SSL. This will prevent any capturing of the tokens from url, by a man in the middle. You would also need to be very careful about when the users browser may use this url in places you didn't expect..
I can vaguely recall reading about a popular site being affected by their urls being used as Refer Url, when displaying ads on their website.. which means, the advertisers site would probably get the url with the token as Refer.
Generation - Choice of algorithm to generate the token - May seem pretty obvious, but the token should be extremely obscure and near impossible to guess or brute force. The tokens should never be reused and the algorithm should avoid collisions.
Server Side Security - The tokens should probably be treated with same security as you would secure users id and password. If your user database gets hacked, hackers should not get the users passwords and other sensitive information.. Similarly, if your user / resource / token database gets hacked, despite the expiration on the tokens, hackers should not be able to access the resources as users for x hours.
Point is, when the tokens are stored on server side, they should themselves be secured / encrypted.
On the same lines.. just like its bad practice to log information like passwords in log file (specially plain text), You'd also have to consider any place these urls may get logged (plain text) on your server.. For example web server logs. If only super admins should have access to user's database, then they should also be the only ones to be able to see these token.. Not your web server admin and not any hackers parsing the log file after the hack.
Auditing - If there will be a need for auditing, you'd need some mechanism in place to prove that while the user didn't log on to the system, they are indeed the ones who performed the action / operation in question. Would you want to track the ip address and other information along with the request which would help such auditing?
Consent - Do your users even consent to the use of such alternate means of authentication and authorization? Should this be an optional / opt in feature?
EDIT: I found a link to the referrer url problem I was recalling. Although it was in context of user information.
I agree to 10 points of Vikas however from security perspective I have to tell you few points that you must be careful.
I will try to keep as simple as possible. And here I simplify the technical stuff to your special case.
Firstly tokens are used to prevent Cross Site Request Forgery attacks (XSRF). Keep that in your mind. If there is a web platfrom without unique tokens on the forms then any attacker can force the user to make malicious requests.
If you simply try to authenticate the user with a token, this is pretty wrong. Because there must be no simple authentication process and you can not rely on token.
Here is how the login system works in official security documentations, im writing as I remember:
Identification: you have to identify the user firstly, that is generally done with username. YOu will know that there is a user exist in your system.
Authentication: Let's say you have already identified that user A want to login. So you mast authenticate the user A with something that you know and user A know. We call it password simply :) You cannot by pass this step with plain text methods. Passwords are generally encrypted in your db and also through all communication with secure certicates, check ssl.
Authorization: okay you made the authentication somehow, the user has a right to get Authorization. Let's say if the admin type user is logged in, he has differen rigts and if the normal user is logged in then she has regular rights.
Session control: finally you have to control the session with a secure way. Here generally in web applciations people use access tokens for all requests to be sure that the authorized user is aware of the request. As a platform owner you are responsible to secure everything until the session ends. If you don't satisfy the users with your security, then probably your platf is not going to survive longer.
Tokens have different lifetime to expire and different access rights.
Now let's look at what facebok like companies do with mobile aplications. For the mobile app they generate a unique access token which is alway alive. One shortcoming here is, if any attacker steal the mobile token generally she can do anything in the account anytime :) Anyway here our point is how they verify the users with those tokens; firstly the token is unique for that device. (Actually not exactly unique or not dependent on hardware, because if you clearly steal the necessary files from the device then you can use it on another phone). So with this unique access token which is generated with users password at their initial login on mobile app, they can login always automatically with that. And this method is a little similar to what you want to do. However pay attention that they don't authenticate the users with links or email code.
Verification is not an authentication, don't forget that. By sending e-mail you can verify the users if the emailed code is unique and valid for only 30 sec or 1 minute. I hope you got the point.
Here I suggest you to check single sign on across multiple domains, which is really interesting.
Single Sign On across multiple domains
Let's say you are logged in to google.com and then you visit the youtube.com Opps the youtube is already logged in? Yea, cool right, but exist for long time. They can authenticate users accross domains which use different cookies with a little and secure trick. You will read on the link.
If your service is not really confidential and if you want to make your users happy with easy login system. Here is two of my solutions which I love :)
1-) Ask users their email address: just directly send 4-6 digit code as e-mail. Ask user the enter/click on that. There will be no password at all, only unique code on each login.
2-) Let's say you need to verify the user with a stronger way than email. Then mobile phone :) Here trick is; you will not send the verification code to user, but they will send what you tell them to you.
Ask to user to send a SMS with a unique CODE to XXXXXX your number :) Connect your mobile operator with your web service and check whether the code is sent to you by the user :)
There is always a trade-off between security and simplicity, and also with complexity. You have to find the balance.
Don't try to make it simple if your security is going away.
Don't try to make it complex if it'll seem more secure.
Hope those informationn help you.