My website has no user registration (members are pulled through from an offline db) and the area that you can login to doesn't hold very sensitive information.
So I want a basic login with a remember me function.
• After checking input against the DB, I plan to store their user_id, name, email in a session.
• For the remember me, I'd store a cookie with value = user_id:randomcode. The random code is generated at login and stored in a field on their user record.
Is this secure enough? or how could it be improved without getting too complex.
You should use the user_id:randomcode only once and generate a new one when the old is used. Read Persistent Login Cookie Best Practice.
Related
I have a website that authenticates users with the active directory. This website is made for internal company use and does not hold any sensitive information. The website is secured with SSL. When a user logs in, his/her username and password will be transmitted to the server through POST. I then store his/her username in a session cookie with a TTL of 1 day, refreshed by every single web action. From this point on, every webpage will check to see if this cookie with the username exists. If it does, it will allow users to access that certain page. Login out will just remove this cookie.
Would this way of authentication be acceptable? Is there a better way to handle user authentication? Is it necessary to use sessions instead and store session id's in cookies?
It does work out nicely to use Sessions, yes. I don't know what language you'd be using, but storing information in general locally is a good idea (this does not include sensitive and private information, ie. passwords).
Pages usually check your authentication (and its type) upon loading.
I've lost my touch with PHP, but for instance ASP.NET has a pretty neat (but complicated) Identity system where your login information would be stored in a separate Session, and destroyed upon logging off, but also stores information regarding its Type. This would later allow the developer to mark pages that would require a specific type of an Identity. For example:
[Authorize(Roles="admin")]
public ActionResult Index() {
// Your action information
}
Again, I'm rusty with PHP, but I imagine it's similar where you'd simply check the Sessions before the <html> tag, ie.
<?php
if(is_null($_SESSION["user-info"]["type"])
header("Location: index.php");
?>
<html>
...
Overall, the way you use sessions in each of the back-end web development languages could defer, but the overall usability is the same. You'd use Sessions to store User information, Store "basket" items, etc.
Passport by default allows the same user to login from multiple browsers and have unique sessions created. How can I configure it to destroy the first session when the user tries to create a second session?
Currently I'm using the 'Sessions' model to add the username to the record and upon subsequent login check by username if the sessions exists. But this increases traffic to the db. I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified. I'd be thankful for ideas around how to achieve tweak with express for this purpose or any other workaround/suggestion.
Much thanks!
I saw that at least 4 users upvote this question, so I decided to create passport-strategy for that. The new strategy called passport-one-session-per-user. It's open source strategy you can access here: https://github.com/AminaG/passport-one-session-per-user
How to use it? add it right after session. For example:
app.use(passport.session())
var passportOneSessionPerUser=require('passport-one-session-per-user')
passport.use(new passportOneSessionPerUser())
app.use(passport.authenticate('passport-one-session-per-user'))
Not need for settings, or configuration.
How it is works?
The strategy, created an array that contain serializaed user objects, and sessionID.
Every time user logged in, the strategy check if the user already logged in. If so, it's flag the other session. The next time the user in the other session make a request, the strategy see the flag, and log the user out.
I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified.
I believe the session model loggs the user in, and saves only that logged-in-ness in the session cookie. The server itself has no clue about who is logged in, but just checks this state in the (signed) session cookie provided by the browser.
You can write your own Passport.js strategy to handle it differently.
I haven't had to tackle a login process before so this is new territory for me and all I seem to be finding on Google are conflicting methods of handling this process, so I was hoping someone could help clarify.
So far I have a salted SHA1 hash made from mixing username, password and my salt variable.
When the user logs in their credentials get hashed, then this hash gets sent to sql and if found comes back with a UserID (or something). So I know they are authenticated.
With that I can handle their session with session variables.
Is that right so-far?
Anyway, I wanted to have the option of "remember me" and was looking at storing something in a cookie but am not sure what to put in there as, as-far-as I am aware storing the hash would be pretty much the same as putting their username & password in plain text.
I'm confused, can anyone shed some light?
Thanks in advance
You are usually better off using the authentication methods provided by your platform than creating one yourself. There are a lot of non-obvious problems that you can easily leave yourself open to. Which platform are you using? Are you using a web framework?
General purpose hashes like SHA1 are inappropriate for password hashing as they are optimised to be very quick, when you want something that is very slow. For discussion of this, see How To Safely Store A Password.
Anyway, I wanted to have the option of "remember me" and was looking at storing something in a cookie but am not sure what to put in there as, as-far-as I am aware storing the hash would be pretty much the same as putting their username & password in plain text.
Hashes are designed to be one-way functions, so no, it isn't the same as putting their username and password in plain text. However if you do it that way, you'll have to create a way of letting somebody authenticate with the hash instead of their username and password, and that is the same as storing their username and password on the client (as far as you are concerned, anyway).
I like the fact that you have used salt for your hashing but I don't think it's necessary to use the username for hashing only password+salt should be enough. Specially it will inflict an overhead of rehashing if you want the option of changeable usernames for your system.
For remember me option, I don't think you should store any credentials at client side cookies. Only the session ID should be enough. If you want to make it really secure you should use client-side certificates that are issued by the server.
http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500
Your first login process is correct and up to todays security standards with the only exception that you may want to choose another hashing function over sha1.
Sha1 is very quick and therefore brute force attacks to crack a hash are faster. So if your hashes (database) and token (source code) get leaked, the passwords can be cracked.
One countermesure is to use a slower hashing function (see Jims answer for an article about that)
But the best of course would be not to leak your hashes in the first time.
A possibility for the remember me function is to let the user keep the session cookie for longer. For example Magento and Zend Auth does this.
This is however very ugly because you are likely to get hundrets of thousands of sessions stored on your servers, even for users that never return.
The far more elegant way is to store this information client side.
Sidenote: Of course you shouldnt put too many cookies on the client because they get transmitted with every page request. But a login cookie is a very valid case to do so. A good practice is to store the login cookie at the client side and populate the server session with data saved in a database at login which is marked in a session. This way you eliminiate continous database requests and have a good user data registry. Of course write has to be done to the database and session directly or better to the database and then somehow flushed to the application (full or incrementally).
Putting the hash in a client cookie isnt like "plaintext". However its ugly and awful and insecure on many levels.
There are some different approaches but they mostly involve some hashing again.
The most common and easy one is something like to put a cookie with user_id=john and user_token=HASH($userid.$appsecret) on the client. Or to store them as one in one cookie.
This is kinda secure but I prefer the following method:
Generate a string that holds:
userid ; user agent ; first two ip segments ; current timestamp ; your application secret token
Run it through a good hashing function and store a cookie at the users client that looks like
auth=userid;timestamp;hash-of-the-above
When the client logs in via cookie you re construct taht string from above but take the timestamp and user id from the cookie. Generate the hash and see if it matches. Then you have validated that it is the cookie you generated for that ip adress segment and this user agent at the specified time
Sidenote: first two ip segments rarely changes with dynamic isps. you can leave them away too, its for extra security.
What is the main advantage of thsi method?
The client or you can invalidate all login cookies by setting a timestamp. Only cookise that have been generated afterwards are accepted. You can also implement a timeout.
This is good if you want to "remote logout" form a public computer where you forgot to log out or something.
I think functionality is very important and with this method you dont have to keep track of single login cookies (like google does).
Hope this helps you.
You can scale this method to any level of security you like and adjust it to your needs.
your authentication is just fine. If you want to make it even more secure you could transmit the login information with a SSL encrypted connection so nobody can read what's going across the network.
The remember token is quite simple let's say you want a remember me function that is valid for 14 Days.
A stranger with no authenticated session comes to your site:
Check if there is a remember me token in a cookie
If yes, check if you can find this remember me token in your database and check if the "valid until" column is still valid (date comparison)
If you find a valid token you can set the user id and authenticate his session
If you don't find a valid token redirect the user to the login page if necessary
When the user fills out the login form and authenticates him sucessfully:
Generate a token using an appropriate hashing function. The token you hash could look like "[Timestamp]---[userpwd]" so it's (almost) definitely unique! Save the token and the date until the token is valid (+14 Days from now as example) to your database connected with the user's id. If there's an expired token, replace it because you don't need to store expired tokens.
If the user logs out by clicking the logout button or similar just delete the token record in your database and the user's cookie.
That's it!
If your platform (web server etc) supports HTTP digest authentication, i would strongly advise you to use it. It was designed by people who know more about security than either of us ever will. It doesn't send passwords over the network. It is supported by all modern web browsers, including mobile devices. If the browser has the password stored, it happens transparently during connection, giving you the 'remember me' functionality without needing to go anywhere near a cookie.
The only thing it doesn't do is let you use a nice form - the use will get a dialog box from their browser to log in.
I just started looking into OAuth and it looks really nice. I have oauth with twitter working in ruby right now.
Now I'm wondering, what is the recommended safe way to store the responses in my local database and session?
What should I store?
Where should I store it?
This example twitter-oauth-with-rails app stores a user.id in the session, and the user table has the token and secret. But that seems like it'd be really easy to hack and get the secret by just passing in a slew of test user ids, no?
The tokens are useless without the consumer key/secret of your twitter app as they're not the same for every app but depend on the consumer key/secret.
To get a session variable you would have to guess the session id which is not that easy to accomplish.
If you want you can store those tokens in the session but I would suggest storing the user tokens in your database with all the other user data so your session contains only the data to identify the user in your system.
Update: I'm not sure if I understand correctly what you mean by accessing the tokens from the database by guessing an ID.
Do you have any authentication in place so that the users have to enter some credentials to access their data? You should store the tokens the same way you store the users email address or password and only authenticated users should be able to access it.
If you're developing a web application you can add a hidden field to the form the user submits, with some hash-like value calculated with the user.id so evil guys cannot change that value and just "guess" for an access token
I'm looking for a good way for my application to know if the person needs to login (again) or not.
So meaning, if a person first uses the app, he needs to login. These login credentials are being verified by a webservice I've build. And after he is succesfully signed in, the next time he uses the application he doens't need to login again.
I've been looking around, but haven't found a clear solution.
I have read a few possibilities to handles this:
Storing this in a local database
Using the 'Settings plugin' from James Montemagno
Using local storage
Using KeyChain (IOS), KeyStore (Android)
It is not my entention to store the login credentials, only to remember if he has signed in previously or not.
Thanks you
You can use the 'Settings plugin' from James Montemagno to store a Boolean value ( LoggedIn = true or false).
But you might want to add a but more logic to your app. If someone is logged in, they should have a token that they'll use to communicate with your server...this token should have an expiry date and you should also have a refresh token.