I have a website that uses OpenID to sign in users. The library I'm using, returnes a user profile when the user logges in. This profile contains user's email, name, a link to the avatar and an ID which the OpenID provider has returned.
My strategy for keeping the user logged in is this:
When the user logges in for the first time, I create a hash code based on the OpenID's returned ID
I store this hash code alongside the user's ID in 2 cookies.
When the user comes to my website, I check for these cookies, and if they're available, try to match the ID and the hash code, if it's correct, I log the user in.
Now the problem is this: if somehow this cookie information gets stolen from the user, the hacker can easily log in instead of the user himself. I could create a new hash code for each time the user logges in and update the user's cookeis but it'll make the information of other browsers/computers cookies invalid.
Since the StackOverflow website does not suffer from such problem, I would like to know what should I do to both secure my login strategy and add the functionality to stay signed in for the users.
The standard way to do this is to assign a meaningless session ID and send that as a cookie; in your database, you can store the user's credential information alongside that session ID. When a user logs out, you can invalidate that session ID.
Isn't this a problem with ALL mechanisms for letting the client stay logged in? If you log into your, say, gmail, and I steal your cookies, and put them in my own browser, there is no way to distinguish my browser from your browser and I get access to your gmail. There's no way to stop the kind of attack you're suggesting, I believe (other than the user keeping their computer free of viruses etc. that could steal the cookie)
Related
I am trying to create web-forum with user authentication, using Github and Google. I've already managed to get user information with access token, like login, email and etc. But I don't get the workflow for authenticating this user in my database.
In order for user to register, he need to provide email, login and password. All the examples and tutorials I saw, was stopping at the sessions and that's it.
My website has database with posts and comments, and to fetch, for example, user's created posts, I need to get the user id, then I will lookup in the database. I thought, maybe, I can use access token as a password, since it's unique, but it always changes and has an expiration date. Then I thought, to left the password input empty and register user without it, but I think, that's not very secure. How should I do it?
I want to create a login system using JWT and have these questions:
1- My client login and I generate a token for him/her and store the token in local storage. Now If somebody else copies this token from local storage of this person browser and paste in his/her (I mean hacker) browser local storage, this hacker will able to log in? If yes, is that safe?
2- I put user Id in the token that I generated On login function. On each request that is sending to the backend, I decode token and find userId in it. Now should I compare this user id by anything? Example checking that is there any session by this user ID in backend or even checking the user Id by DB?
3- should I put an expiration time for JWT token on the local store?
1 - It's safe to store these in localStorage. It is worth checking out how to protect against Cross site scripting attacks; this is particularly true for high security environments. Users copying and pasting is probably an unlikely attack, and, if the user has physical access to do the copy and paster, there are probably other 'vulnerabilities' like just using the browser's stored passwords.
2 - The JWT encrypts the user id included in the claim. A user can't change this claim and keep it valid (assuming a strong key), so no need to check this elsewhere.
3 - Yep! Since the JWT has a claim (like the user roles) in it, you don't want those to be valid for forever. Also, you want to have a way to ensure that users re-verify their identify (ie. log in again) just in case something goes wrong/a token is stolen. When you put an expiration on the token, you force this.
I am building a website using Node.JS/Express.JS that will allow a user to log in using a 3rd party provider (Discogs via OAuth1.0a).
I have successfully implemented the authentication process so that a user grants access to their Discogs account and I am returned an Access Token for future API calls. The Access Token does not expire. The user is classed by Discogs as an "authenticated application".
At the moment I am storing the Access Token in a session, which persists even when the user restarts the browser, or my server is restarted, so the user stays logged in. Great.
However, when I log the user out by destroying their session and they repeat the authentication process, the 3rd party provider treats the user as a newly authorised application, leaving the old authorised app behind. How can I get around this? Is it better to not destroy the user's session on log out and instead store the logged in state of the user? Discogs do not provide a method for de-authentication.
Also, there is some config to be set against a user once they are logged in. Should I created a dedicated DB table or equivalent for this, or would storing this in the session suffice? It seems like a dedicated user table may be superfluous as I am relying on the user's session id to identify them.
Generally, you will probably want to save some info about your users permanently on your own servers, so probably in a database.
In your specific case, that database should probably save some kind of unique user ID that you get from Discogs (do not save the access token itself for security reasons), which you can use on subsequent logins to identify which access tokens belong to the same user.
Your flow would probably be something like this:
User logs in via Discogs for the first time, you get an access token, put that in session
You figure out a unique user id somehow, you save that to your DB along with any other user info you might need
You put that ID in the session as well
User logs out, you destroy the session, but keep the info in your DB
User logs in via Discogs again, you get a different access token, put that in session
You figure out the unique user id, which matches the ID in your DB, so you write that ID into your session - now you can treat the user as the same user, just with a different access token
The unique user ID can be anything that is, you guessed it, unique. Might be an actual ID, a username or email address - I'm not familiar with Discogs but I'm sure you can figure something out and how to obtain it.
I am planning to use only cookies (and not sessions) to authenticate users around the private section of my website. I want users to stay logged in indefinitely, unless they logout themselves. It will work like this:
1. Upon successful login I generate a random hash and store it as a HTTP cookie on the user (using SSL). I also store the hash in my database, along with the user id and the user's device.
2. Whenever a new page is requested I check to see if the user has a cookie. If he has I get the hash and search it in my database. If I find a match and the device is the same I assume it's the user and give the page. If I can't find the hash or the device changed I assume it's not the user and ask for login again.
My question: would this method be acceptable, security-wise? I can't see why this would be less secure than using sessions (keeping the users logged in in both cases), as in the end the risk is the same, which is having an attacker discover the hash to impersonate the user. My defense against this is tracking the users device, so the attacker would need to discover the hash and have the same device.
Thanks for your feedback.
What you're describing is basically the session functionality offered by most languages/frameworks.
Just make sure your hash values don't use the time the user logged in as a source of entropy, ie. don't use h(username + login_time) because this could be brute forced fairly easily if the attacker knew the approximate login time.
What language / framework are you actually using? You'll find in most cases there's an option to use the session "functionality" with a persistent cookie (rather than a session one) which would save you implementing this from scratch and possibly creating additional security concerns.
I’m developing a website of a client and they are sending out newsletters to their customers (through the website administration interface)
The newsletters are personal to each of the subscribed recipients/customers.
Each recipient/ customer is also a user with a username/password that enables them to sign in on the website and manage their newsletter subscriptions and participate in the sites community.
This all works like a charm.
Now my client want a “Manage my subscriptions” link in the newsletter email that when pressed automatically signs the recipient/customer in on the website with no need to remember username and password.
This could be easily solved be making a link like this:
http://mysite.com/manage.aspx?user=peter&password=hounddog
Of course information should not be clear text but encrypted in some way.
This however poses a problem since the only way a user can be authenticated on the website if by providing a valid username and password.
In the name of security, passwords are stored as hashed values in the database making it impossible for me to insert the password in the link.
What is the best way to accomplish this without compromising the security?
You will have to compromise your security somewhat, if you want people to be able to login without entering password. Note that even if you had access to the password (as in your example), you would have to embed it in a mail massage which would be transmitted in plaintext.
You can create a Guid associated with each user and message, and append it to the URL, and allow that to login automatically.
You could perhaps isolate the permissions so that a login through a newsletter guid link only allows the user to manage subscriptions, but that a real password-login is still required to participate in the forum. In that case its pretty limited what havoc can be wrecked if someone gets access to a Guid from a mail message.
Could you not insert an encrypted user name bundled with the hash value of the password?
What I mean is, encrypt & encode the user name to always be a particular length or to have a known break character in it then append the passwords hash value. this way, you could break apart the query string easily while still having the user name and password securely encoded. A straight compare of the hash values would be enough, with the unencrypted, decoded user name to allow access.
What about using an encrypted cookie that contains an access token ?
This cookie would be delivered after a successfull authentication by a separate page.
This kind of token can also be part of the URL query string.
Also you might consider using secured https instead of http.