Is it a bad pattern or a best practice. Say a user has successfully changed his password after "Forgotten password". Do I need to redirect him to the login page and prompt him to log-in or should I automatically log him in to the application?
If either, why?
I can't imagine any security advantage of requiring him to login after he successfully changed password with forgotten password. However, there may be usability benefits such as: (1) reinforcing in the user's memory what their new password is, and (2) allowing their browser to store the new password so that they do not need to type it in next time they login from that browser.
It is fairly common to redirect the user to login with that new password.
The OWASP recommendation is actually:
Whenever a successful password reset occurs, the session should be
invalidated and the user redirected to the login page.
For more info see this answer:
Password reset functionality is often used when a user wishes to
secure their account.
By invalidating all existing sessions upon password reset, the system
is making sure that only the person with the new password can login.
Say, for example, an attacker that has gained access to the account
using the old password is logged in. Resetting all sessions will log
the attacker out.
This might also be used in a forgotten password scenario if the attacker has managed to update the user's password to prevent login, but for some reason hasn't updated the email to one not under the control of the real user. This could be because updating the email address causes an alert to go to the old address, and the attacker doesn't want to risk creating any unnecessary noise (although it is also good practice to send an email to the registered user upon any password change).
Actual redirection and logout isn't really necessary though. This simply needs the session identifier of the current session to be rotated, and the session identifiers of all other sessions to be revoked. This should prevent access by any attacker riding an existing session. There are a couple of advantages though as detailed in TheGreatContini's answer.
Related
I am creating a web app on a LAMP stack where I have users with their own logins and passwords. Typical users of the application have limits on operations. For example they cannot approve an order over $5000. If there is an order over $5000, they have to get a manager to come to their desk and enter in his/her username and password to approve the order.
I can easily create a form for the manager to enter his/her credentials into an HTML password input, but here is the problem. When the manager enters their credentials into the browser, the password field is hidden from the user. But when the form is submitted, the password is transmitted in clear text. In theory, a user could get the password by using F12 or by looking at the POST.
I wanted to hash the passwords before submitting the form, but the problem is that PHP stores the passwords using BCRYPT, and javascript can only digest with SHA.
So basically my question is. How can I ensure that the manager password is hidden from the user and they cannot get it?
javascript can only digest with SHA
I'm sure you could find implementations of bcrypt in client-side Javascript…
That won't really solve your problem though. If the password is hashed client-side, then the server cannot hash it further and needs to accept the hash as is to compare it directly to the stored hash. Which in essence means, the hash becomes the password, so the user could send the same hash again to the server and pass the test.
Further, bcrypt should be using random salts, so in order to recreate the same hash, the server would need to send the used salt to the client so it can create the correct hash. This is all madness.
Instead, you probably want some sort of challenge protocol. The idea being that the value the client sends to the server is different every time, so even if the attacker sees the value, they cannot reuse it. For this purpose the server would make up some random value, send that to the client, the client calculates some answer given the password and the random value, and sends only that to the server. A rough overview of different algorithm can be found at MDN and elsewhere.
This still won't solve the issue of the attacker installing some keyboard logger, or simply overriding some Javascript handler to log the entered password to the console before answering the challenge. In the end, if you don't trust the attacker and the attacker has full control over the system the password is entered into, there's nothing much you can do.
Basically I have an SQL table with 3 values, username, password, and a cookie.
dog - cat - a8bfc7ec7a2b0ba10977fddd59fc403d
On login it checks if the username and password match, then it generates a random md5 hash, inserts it into the database then sets it as a cookie for the user.
Once using the site it will check if the cookie matches up with any in the database to verify they are logged in.
How secure is this system?
If I understand correctly, you are using a random md5 just as an ID to identify the client between requests without using his password. This is similar to a session cookie and will have similar security issues.
If you rely only on this cookie, anyone who steal the cookie will steal the user's account. You could extend the verification by fingerprinting the user, checking the user-agent and anything else that is unlikely to change between requests. Note that the IP may change. You could also still ask for the user's password before important actions, such as changing the user's email or password.
Note that it's not very difficult to access the user's cookies, even a browser extension can do it.
I am creating a login for my chrome extension where I am going to be using the firebase email and password.
I am going to be putting the create User firebase code on my website and when someone can enter in there email and the script will create a random set of digits and set that as the password. It will then email that password to the user and the user uses the email he entered and the random digit password he received via email to login.
My question is If a user signs up and then logs in with his email and password. Whats to stop him from giving that email and password to his friend and he also logs in. I want to control the amount of users I allow within my chrome extension and only want the person who logged in to use the chrome extension (I want so the login can only be used once) Is this possible for firebase or not?
Also If anyone knows a simpler method than that I described above with sending the email please let me know becuase to do that above I have to create something that sends an email and creates the password.
I would also like to know if firebase has something where I can set a date on a user and after that date passes the user is logged out and has to register again.
But my main question is that if a user where to register if he has the ability to share the login with his friend or if only he can use it.
I really appreciate your reply and help on my issue in advance Thanks A lot.
You'll likely have to do this from the server side (e.g. in a Cloud Function).
One option would be to use the session management features in the auth admin SDK: https://firebase.google.com/docs/auth/admin/manage-sessions - if you report back from the extension with the logged in user, you can revoke access for users who are seen in too many places at the same time. This limit might not be 1 - you may want to allow your users to log in on multiple machines at once.
For even more control, look at the option for managing your own session cookie: https://firebase.google.com/docs/auth/admin/manage-cookies - this allows you to set your own expiry and control the logged in state more granularly.
I have an app for user authentication and I ran into this issue where I have user who logged in and has the JWT (JsonWebToken) stored in the cookie. I stored the cookie after I validated the user. Next I, as the admin, remove that user from the database while he/she is still logged in. The since user is still logged, the user has a valid JWT in the browser, so it still thinks that it exists because the way I validate if a user is logged in is through the webtoken. I have been thinking about how to fix this but I haven been able to come up with anything yet.
I also posted this issue on GitHub.
Take a look at Invalidating JSON Web Tokens
There are several techniques to invalidate a JWT token before its expiration when the user situation has changed and you can not not remove from localStorage/cookie: account deleted/blocked/suspended, password changed, permissions changed, user logged out by admin:
Token blacklist: Store tokens that were between logout & expiry time, mark expired and check it in every request. You need server storage. You can include only the ID or use the issued time field. Tokens issued before last update of user would be invalid
Expiry times short and rotate them. Issue a new one every few request. The problem is to maintain user logged when there are no requests (for example closing browser)
Other common techniques:
Allow change user unique ID if account is compromised with a new user&password login
Include last login date to remove old tokens
To invalidate tokens when user changes their password, sign the token with a hash of their password. If the password changes, any previous tokens automatically fail to verify. Extend this mechanism with other field of interest to sign. The downside is that it requires access to the database
One way would be to make the cookie expire by settings its expiration timestamp to a date that has already passed.
Sorry for the generic title. I'm playing around with Mozilla's Persona at the moment. I'm using Express.js with the express-persona middleware so setting everything up was incredibly simple. The client-side part is easy too, but I'm having a hard time understanding one particular part of the documentation. It says:
loggedInUser: The email address of the user currently logged into your
site from this computer, or null if noone is logged in. For example,
you might examine the browser's cookies to determine who is signed in.
[...] Persona will compare the email address you've passed into
loggedInUser with its own knowledge of whether a user is currently
logged in, and who they are. If these don't match, it may
automatically invoke onlogin or onlogout on page load.
(Source)
express-persona sets a cookie which includes (I guess) the crypto-foo that acts as a password replacement. Am I supposed to store the email address returned by the backend in a separate cookie? That doesn't seem to be a very good idea. Maybe one of you guys knows how that's supposed to work.
You wouldn't store the email address in a cookie for Persona, any more than you'd store the username in a cookie for a password-driven login.
No, basically you do the same thing with Persona: Use a session, stored on your server, keyed from a cookie. The only difference is that your site went through the Persona auth process, instead of verifying a username + password.
The example on the page you linked to has a currentUser variable. Well, in a real web site, that variable would be filled in as a template from the server side. Do whatever you would do to support a login session, find the currently authenticated user, insert that user's email address.