I have a single-page AngularJS app, and authenticate my website via websockets using no cookies. This means a refresh logs the user out. How bad is it to store the password on sessionStorage, so they can refresh during the session? (The username will be in localStorage, and I don't want the full login to persist between sessions).
Thanks!
EDIT:
What I'm more interested in is if there are there any actual security risks for storing in such a way. Is it any less secure than how Chrome stores passwords in plaintext, or how cookies are unencrypted?
Are you trying to avoid localstorage, or just cookies?
You could store a session ID in the session storage, and authenticate the user using that, under no circumstances would I store a users password cleartext though.
I don't think you'd want to store the password. You could generate a session token and store that in the sessionStorage. Anyway, if you come to store the password itself, don't store it as plain text.
What you want to do is... create some hash on your server, and save it on the localStorage.
Send this hash on each request, and the server should validate/handle it, and respond with the appropriate credentials.
But that is also 'not as secure as you may want it to be', so... you can change the hash every x minutes, or have it time out after X minutes of innactivity.
Never store plain text passwords, and never include your hashing algorithm on the client side.
Related
I am developing single page application that would require sensitive data user password and private key. However, I would not want them to key in a password each time when it is needed.
What is the safest way to store this during login, without compromising security? I do not want to store it in localStorage, neither sessionStorage which are unsafe.
If you want to access this information inside your JavaScript code - then there is no secure way for that, the hacker can simply put a breakpoint in your code and inspect the relevant variables.
If you only need this info in order to maintain a "session" with the server - then you can use an encrypted session cookie, marked as HttpOnly and SameDomain. The cookie is called "session" because it automatically expires and disappears as soon as you close the browser. And it is encrypted (using a symmetric encryption like AES-256) so that only the server can decrypt it.
The cookie itself does not need to contain the password - it is enough to contain these 4 pieces of information:
user ID
IP address of the browser (to prevent using the same cookie from different locations)
timestamp of the last change of user data in DB (to invalidate the cookie as soon as the user changes his/her password or other sensitive data in their profile)
timestamp when the data inside the cookie should expire (to prevent using too old cookies)
Usually the data in the cookie should be considered expired after 20-30 minutes but you may choose to allow the user to set this time as a preference (with a maximum of 60 minutes).
And this cookie should be updated/refreshed with new expiration every time your SPA makes an AJAX request to your backend API.
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.
currently I'm working with cakephp and implementing user management in my project.
today, i came across an issue in user session.
i have generated a cookie to remember user's password in encrypted format
The cookie restores session if users session goes expired.
now i have tried transferring cookie to other browser from chrome to Mozilla
using a cookie manager plugin.
and i have found myself logged in in both browser what is the best way to prevent this.
??
You can't prevent this. However, you can reduce the problem by having a session value generated server-side when the user starts a new session, which is some hash made from
The session ID
The user agent (attacker would have to use/spoof the same client)
Possibly the IP (would only work for fixed devices, but makes it much harder for an attacker)
Now when a logged in user tries to view a page requiring you to be logged in, you can compare more details than just the session lookup.
It's not impossible to spoof, but this reduces the problem.
This hash should never be actually sent to the client, just kept in the session information server-side.
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.