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.
Related
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.
This is a pretty open question but I just can't get a straight answer no matter where I look. The question is in the title but...
Should I return the user's encrypted password or token on user login
Extra Info
I'm running a MEAN stack application with Angular5. I'm using sessions for the user and storing it in MongoDB. So from what I understand, the session cookie is what used to authenticate the user for extended sessions and not the password (I haven't gotten to Facebook or Twitter strategies but from what I understand the cookie verifies the user instead of the token that Facebook/Twitter gives me correct?).
I do want to pass user data to my Angular application and store in the browser local storage for quick, non-server-side verification that the user is logged in. This is only for aesthetic reasons such as displaying username and profile picture. Restricted POSTs and GETs still require server-side verification using a passport. So my question is since the session is saved in the cookie, is there any reason to send the password or token to the user/browser? Even though the password is encrypted (using bcrypt), it still seems like an unnecessary security hole to send it at all. Is there a reason that I might encounter in the future where I would want the password stored in the browser?
The quick answer is no, you do not and SHOULD NOT pass the sensitive data back to the front end.
What I normally do is when I return a "User" object back as a response to the front end, I run it through a helper function that filters out sensitive data such as the encrypted password and the salt, etc...
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.
I have a website which clients can log in to. Their username, encrypted password and some additional info is stored in an SQL database on the server. I am setting up a cookie to remenber the user for some days.
I read everywhere I should not save the username and password in the cookie for security reasons. I have to say I am not sure to see why. The cookie is stored on client side right? Thus it is his username and password he is able to see, what is unsafe in that?
Anyway I pretty sure there are good reasons and it is just I cannot see it, I read the solution is to do that:
hash and encrypt the password
store the login information to a file on the server
give the file a unique name
store the name to a cookie
each time you receive the cookie with the correct file name, look up the file and retrieve the login information.
So I should generate a unique ID to store in my database and associate it with the user.
How can I achieve that?
You don't need to store the username and the password. You could instead store a session key (saved in database) with an expiration date.
If you store username and password locally that is not a huge problem if the user is at home, but what if the user is not at home ? What if the user is not on his own computer ?
Even encrypted, some "bad guys" could get it.
The problem is that the user can change the cookie value. So he can set the username to someone else's name.
Instead of putting the username in the cookie, put the unique filename in the cookie. This is essentially how PHP sessions work -- they put all the session data in a file, and set a PHPSESSID cookie with the name of the file.
should not save the username and password in the cookie...not sure to see why
Because the user may not be in exclusive control of the client - e.g. a public access terminal, or even with a personal computer, this extends the attack surface for malware. The longer lifetime of the entity compared with a session identifier increases the attack surface too.
And if it's not properly encrypted and re-validated then the user can easily change the data to that of someone else.
As to the remainder....
give the file a unique name
File? What file? You are trying to implement a surrogate authentication token. The specifics of how you do that depend on the programming language and the policy you want to implement. Should the system allow for the user to store tokens on multiple machines (which implies multiple concurrent values)? Should it be strongly tied to the machine it was initially assigned to (in which case how do you establish the identity? Using the IP address or user agent has limitations)?
Generally you should store the mapping between the token and the account (and additional meta data such as machine identity and expiry) on the server.
I'd like to securely save a user's credentials to related web sites and automatically log them into those sites when they log onto ours. I understand there are some security implications to this, so I'd like others' feedback and see what has been successful for others in the past.
What technique have you used to auto-log the users in? I'd prefer not to have to duplicate the HTML form and submit it through javascript. This seems error-prone if the form ever changes. I tried putting the login form inside an iframe, but it seems like the owners of the site are able to block this (see attached screenshot). Do you know how they do this?
Secondly, what was your approach to save the credentials so that they were "safe".
...Peter
I would suggest using cookies to save a session certificate to the users machine. A good value for such a cookie would be;
userid, timestamp, hash(userid . timestamp . global_secret)
The value of global_secret needs to be very long (40 characters or so), to avoid people cracking the hash, as doing so would allow them to create their own credentials with other peoples user ids!
The 'other sites' would check for this cookie, calculate the hash using the cleartext values of userid, timestamp and the global_secret (which all sites know), check it against the hash supplied, if they match, then this is a valid certificate.
You would then need to check the timestamp and decide if this was a 'new' enough certificate to allow access.
This is the standard method.
Do not do this. Read the terms of services for each site (ie facebook):
https://www.facebook.com/terms.php?ref=pf
(3.2) You will not collect users' content or information, or otherwise access Facebook, using automated means (such as harvesting bots, robots, spiders, or scrapers) without our permission.
(3.5) You will not solicit login information or access an account belonging to someone else.
(4.8) You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
You put yourself and the user at risk.
These sites have an API for a reason, so I suggest you looking using those as a more "legal" approach.
So if you're trying to retrieve a facebook user's information, create an app, have them authorize your app, then retrieve the information through facebook's api (example). You can also post to their wall with this method.
https://developers.facebook.com/
https://dev.twitter.com/
https://developers.google.com/
The common method to auto login a user is to set an cookie with an random string. It have to be that the random string isn't guessable. At the server you check the cookie and if it matches then you login the user. But if your site isn't completely served with https everyone who can listen to the traffic can pretend to be the user. To increase the security a little bit you could implement that a random string is only valid for a view days and then the user has to login again and a new random string is generated. So if someone steals the cookie-id the attacker has only for a certain time access to the account.