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.
Related
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 just developing a Web-Add-In for Outlook 2016. I would like to save username and password, so the user does not need to fill in this data every time.
How can you realize this in a secure way with JavaScript? Code Snippets are welcome.
I would like to separate your question into two as follow ...
I would like to save username, so the user does not need to fill in this data every time.
There is very convenient object in Office.js API: RoamingSettings. The settings created by using the methods of the RoamingSettings object are saved per add-in and per user. That is, they are available only to the add-in that created them, and only from the user's mail box in which they are saved. Basically username is the perfect candidate to be stored in this object.
I would like to save password, so the user does not need to fill in this data every time.
The RoamingSettings object should not be used for the passwords, tokens and other authentication data. Documentation clearly stated the following ...
While the Outlook Add-in API limits access to these settings to only the add-in that created them, these settings should not be considered secure storage. They can be accessed by Exchange Web Services or Extended MAPI. They should not be used to store sensitive information such as user credentials or security tokens.
As the common sense, storing user password into insecure store is bad idea. Even storing hash of the password is not that great as JavaScript code is very exposed to the client and user password may be subject to dictionary attack as you will not be able to hide your salting / peppering with JS. The user should authorize to your service (add-in) every time. Bottom line: DO NOT store the user password insecurely in the mailbox.
I have a form that via AJAX validates login credentials from an external php script and database. I am attempting to password protect pages of a Squarespace website.
I am wondering if there is a way to securely store some kind of token returned when the user logs in using the login form that can be checked on each page the user attempts to access and redirects them or allows the to stay on the page based on if they successfully logged in.
I have looked into using cookies, web storage/local storage, window.name and several other methods that other people have used but none actually seem secure and I am not able to use php.
Is there a secure way to do this?
Well, it depends on what you mean by "Secure." By default, for example, PHP's built in Session feature will use either a query string or cookies. The same is true for ASP.NET's Session feature. These are used on millions of websites and I'd say it is secure. The question is, what are you storing in the cookie? If you set a cookie like "IsLoggedIn" with a value of 1, that's not secure. However, if you do like PHP/ASP.NET do and store some random string (ideally a cryptographically secure random string) which is validated server side to a list of logged in random strings, you're good.
But that begs the question, why aren't you just using PHP sessions to store this information? See http://php.net/manual/en/features.sessions.php Then you'd store the IsLoggedIn in the session object which is stored server side, not client side, and you're secure.
I'm building a web application that accesses a private API. The API that I'm consuming uses HTTP Basic Authentication over TLS. My client has requested a "remember me" functionality for the web app so that users can maintain persistent authentication on a given device.
My quick-and-dirty solution is to store the Authorization header in localStorage after it has been validated. Of course, given unmitigated access to a user's device, anybody who is worth their weight in salt could copy the auth header from localStorage and decode it to retrieve the user's login/password combo.
Aside from total device compromise, are there any other security implications from storing this type of sensitive data in localStorage? Is localStorage acceptable as a store for sensitive data such as passwords? If not, how would you persist such data on a user's device beyond an individual browser session?
(I wish everybody could just use his or her private key...passwords are so 90s)
EDIT After reading HTML5 localStorage security it seems clear that storage of sensitive data in localStorage in general is a bad idea, but what better option is there for authentication persistence in this case?
I think it's a bad idea to store something related to the login or the password on the user's side.
But once an user has logged in, you can store a random string (a random hash for example) on the user's side and in your database. When the user get back, you can compare the two and if they are identical, you can log in the user. And you can ask the user to enter his password for sensitive actions (change password or login, etc.). So even if the hash is stolen, no one will be able to get the full access to this account.
Edit : this concept is already used with cookies. I've never tested it with localStorage.
Could I securely use local storage instead of cookies to store session credentials?
Would I need to store an encrypted hash??
EDIT: Would this be secure enough?
User logs in.
Server returns success message including salted bcrypt hash mixing userid, password, timestamp, and possibly ip address. This is saved in local storage.
On future connects this hash is sent, server assumes accountability as long as IP address hasn't changed, and time limit hasn't expired.
localstorage is just as vulnerable to being read by JavaScript as cookies are.
localstorage can be read using JavaScript from the same domain, if you control all the JS on the domain, then this shouldn't be a problem. But if any other code is executed (via injection for example, or if you share the domain with someone else), they will be able to access the storage data.
This is the same for cookies however, but typically the cookie is set to HTTPOnly so JavaScript cannot read it.
In either case, plain-text login information shouldn't be stored in either cookies or localstorage anyhow, as if someone does get hold of them, they can continuously make a new session for themselves.
You should encrypt an authenticated identifier (such as their user ID) along with the datetime of the session expiration, and then store this value in either a cookie or local storage. This token is then validated on each server call.
If you're going to be using local storage, why store user credentials or anything derived from them at all?
What I've been looking into doing is:
Upon successful login, generate a completely random string unrelated to user credentials and store that in the database, along with an expiry date. I would then pass that string to my js to be stored in local storage.
From then on, so long as that local storage credential matches the database one and the timeout has not expired, I automatically consider them logged in.
This way, there is no risk concerning the exposure of the user's credentials from local storage. However, with this temporary unique string essentially functioning as a sessionID, you will still to need to be aware of and take precautions against the risks associated with session hijacking.
In any case, my understanding is that local storage is as secure as the server behind your site is. By that I mean local storage is only accessible via scripts coming in through your own domain, so you're safe so long as the only front code running is your own.
You server shall generate some token - unique (for the server) piece of data that cannot be used to discover username/password. Only that token can be stored on user's machine in any form. Neither localStorage nor cookie are secure. So the same rules applied to them in this respect.
You should have some means to expire such token otherwise once stolen such token can be used instead of real credentials.
If you're going to use localStorage instead of cookies, you can make things more secure than cookies. That's because you don't need to send a session id to the server with each request, making it a bearer token. Instead, you can store a user secret on the client side in localStorage, and use it to sign your requests in addition to the corresponding public key being sent down and used as the session id. This way, no one on the server side or proxy can fake your requests.