HTML5 offline authentication - javascript

I am looking for advice/criticism on how best to control access to an HTML5 application that is used predominantly offline.
The application uses a combination of IndexedDB, local and session storage to store data so that it can be used offline. The data/pages are served via HTTPS.
The aim is to minimise the risk of the data being viewed if the tablet/PC was lost/stolen.
Currently the application uses the Stanford Javascript Crypto library to encrypt the user/password and then save it to local storage if the user is able to successfully authenticate to the server. If the application then goes offline a user must authenticate 'locally' against the encrypted user/password in local storage.
In addition an unencrypted user/password is stored in the session storage if the user is able to successfully authenticate to the server. This is used so that the application can periodically attempt to re-establish contact with the server and 'seemlessly' re-authenticate without requiring the user to re-enter their credentials.
I am aware of a number of posts/discussions about the fallibility of client side encryption refer http://www.matasano.com/articles/javascript-cryptography/ and http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ and .nczonline.net/blog/2010/04/13/towards-more-secure-client-side-data-storage/ + others. However I am unsure how these arguments apply in this scenario.
I am looking for criticism of the approach given the need of storing data offline. If there is a better approach please elaborate.
Thanks

Authentication vs. secure storage
I'll start with the big design issue: You seem to work with the problem as if it is about authentication, where the (potentially malign) user needs to prove to your application that she really is valid user. But actually you are facing a storage problem, because the whole runtime environment, containing all the sensitive information your application is working with, is in the hand of the attacker if the computing device is stolen. In the case of a javascript application the analysis of the offline data and code is even more comfortable than in the case of some binary only code.
For example if I would want to attack your application I would first look into the session storage (cookies? Simply use the browser interface to look them up) and see if I can find the username and password there. If not I would follow the code that is used to decrypt the password in the local storage (probably using a javascript debugger). The way you have described your application it seems like the functions can decrypt it without a key supplied by the user. Maybe I can just comment out the local authentication of the user by changing something like if(authenticateUser()) to if(true).
So what you really have to do is encrypt all sensitive, local data with a key that is not stored on the client side at all. For example ask the user for a decryption key every time he accesses your application, use that key to decrypt the locally stored data (and encrypt every new data you store) and throw the key away after a certain time of inactivity. Or you can authenticate the user against the server every time he accesses your application and retrieve the decryption key from there and throw it away after a certain time of inactivity.
At this point the choice of a javascript environment really hampers your cause as you cannot force the runtime environment to throw away the decryption key when you want it gone. It is difficult enough with C applications even, as you have to carefully work around swapping the RAM out onto the HDD. Depending on how sensitive the information your application works with is it might be enough to ask the user to close the browser after she is finished and assume that an attacker is not motivated enough to look for the key in swapped out RAM of the browser.
Locally saving the login data
As it is the most sensitive information you work with you should never store the user login information on the client. Instead authenticate against the server once and retrieve an authentication token from it for future interactions. This would be basically identical to a session cookie and expires after some time (if it does not expire at all it is as good as the password).

I have now implemented a solution which I describe below in case it is useful to someone else. I do understand it is 'not an answer' to my question i.e. does not offer critique, but given that the application must work 'offline' along with the requirement of seamlessly re-authenticating I cannot see how #Perseids answer can be implemented, although I do appreciate the dialogue (from both #SilverlightFox and #Perseids).
If there is a solution to not having to store the user's credentials 'offline' while fulfilling the requirements outlined in my question I would be keen to hear.
The application must be able to authenticate a user when the application is 'online' and 'offline'. For an 'online' application normally a session token solution would be adopted i.e. only a session identifier would be stored on the client (usually in a cookie) but not the user's credentials. However the user's credentials necessarily have to be stored on the client (perhaps someone will come up with a clever alternative?) so that security can be enforced while the application is offline i.e. allow a user to authenticate while offline and decrypt/encrypt IndexedDB data. In order to make the application more secure, the user's username and password are stored in an encrypted form. Some sensitive IndexedDB data is also stored in an encrypted form. Thus even if a malicious user were to obtain the computer or tablet with a cached instance of the application they would only be able to view the usernames, passwords and data in their encrypted form (provided the user has logged out or closed their browser).
Unfortunately at this time there doesn't seem to be any 'standard' protocol for securing HTML5 offline applications. Almost all literature warns not to store user credentials or any sensitive data on the client. However this is a paradox as this application must work while offline hence the data must be stored offline.
The security protocol implemented here has two keys, although once the first key is cracked it will be easy to obtain the second key. In the first level the user's password is encrypted with their own password as the key along with their username reversed as the salt. There is also a second key, 'data encryption key', that is returned from the server upon successfully authenticating to the server. This key is used to encrypt both the username and any IndexedDB data. This 'data encryption key' is inturn encrypted using the user's password. Thus if an attacker were to be able to decrypt the user's password they would then easily be able to use the password to decrypt the 'data encryption key' and then using the decrypted 'data encryption key' decrypt the user's username and any encrypted IndexedDB data. Only the encrypted form of the usernames, passwords and data then needs to be stored permanently on the client as by using the user's username and password entered into the login screen it is then possible to decrypt any persisted data.
However, after logging in, the username and password are stored in the client's session in their unencrypted form so that 1) the application can periodically re-authenicate with the server, this makes re-authentication seamless if there is intermittent connectivity and 2) retrieve the decrypted data encryption key at any time so as to be able to query/save the IndexedDB data and decrypt/encrypt it where necessary. If 1) weren't a requirement it should only be necessary to store the data encryption key in the session. This leads to a vunerability if the user has not logged out or has not closed their browser since a malicious user would then be able to view the user's password and username in their decrypted form (using a debugging tool). However this is not much worse than the same thing happening to a traditional online application that gives the user the ability to change their password, although normally a traditional online application has a session timeout so the malicious user would only have a limited time to act. Also if the browser crashes, normally it will give the user the option to restore their previous windows/tabs with their session information, hence the browser should be closed properly.
The protocol adopted above almost certainly does not follow best practices. For example the salt is not random (username reversed), is likely to be short, vunerable to a dictionary attack, the same may apply to the password (the strength of the password is a function of the server), there is no key stretching e.g. PBKDF2. However I cannot see how it is possible to follow 'best practices' and fulfill the requirements given the constraints imposed. It may be possible to improve the hashing a bit e.g. improve the salt, perhaps a combination of the username and a site-specific string however even that would require logic in the javascript that could be understood by a determined attacker. The Javascript can be obfuscated but that too only makes it more difficult but not impossible and any person capable of cracking the encryption keys would not find obfuscation of the Javascript much of a hinderance. Perhaps with some future clever inherent inbuilt support from the browser significant improvement will be possible.

Related

How to make the password in the code that should be encrypted with JS only [duplicate]

When I want to put a login system in place, I always compare the MD5 of the given password with its value in the users table on the server side.
However, a friend of mine told me that a "clear" password could be sniffed by a network software.
So my question is: is it a good idea to hash the password on the client side? Is it better than hashing it on the server side?
Basically, your friend is right. But simply hashing the password on the client side is only just better than submitting it as plain text to the server. Someone, who can listen for your plain text passwords is certainly also able to listen for hashed passwords, and use these captured hashes him/herself to authenticate against your server.
For this matter, more secure authentication protocols usually jump through a number of hoops in order to make sure, that such a replay attack cannot work, usually, by allowing the client to select a bunch of random bits, which are hashed along with the password, and also submitted in the clear to the server.
On the server:
generate a few bits of random
send these bits (in clear text) to the client
On the client:
generate a few random bits
concatenate password, the server's random bits and the client random bits
generate hash of the above
submit random bits(in clear text) and hash to the server
As the server knows its own random information as well as the client's random bits (it got them as clear text), it can perform essentially the same transformation. This protocol makes sure, that nobody listening in this conversation can use the information later to authenticate falsely using the information recorded (unless a very weak algorithm was used...), as long as both parties generate different "noise bits" each time, the hand shake is performed.
Edit All of this is error prone and tedious and somewhat hard to get right (read: secure). If ever possible, consider using authentication protocol implementations already written by knowledgeable people (unlike me! The above is only from memory of a book I read some time ago.) You really don't want to write this yourself usually.
First of all, this does NOT improve the security of your application (assuming it is a web app).
Use SSL (Or actually TLS, which is commonly called SSL). It is free and easy to set up with Certbot.
The why to this is simple. TLS solves a problem (when used with a certificate from a certificate authority, not self signed) that is quite big in cryptography: How do I know the server I am talking to is the server I think I am talking to? TLS Certificates are a way of saying: "Me, the certificate authority, trusted by your browser, certifies that the website at [url] has this public key, with a corresponding private key, which (private key) only the server knows, look I signed my signature all over the document, if anyone altered it you can see".
Without TLS, any encryption becomes pointless, because if I sit next to you in a coffeeshop, I can make your laptop/smartphone think I am the server and MiTM (Man in The Middle) you. With TLS, your laptop/smartphone will scream "UNTRUSTED CONNECTION", because I don't have a certificate authority signed certificate that matches your site. (Encryption vs. Authentication).
Disclaimer: users tend to click right through these warnings: "Untrusted connection? What? I just want my pictures of kittens! Add Exception Click Confirm Click YAY! Kittens!"
However, if you really do not want to use a certificate, still DO implement client side Javascript hashing (and use the Stanford library (SJCL) for that, NEVER IMPLEMENT CRYPTO YOURSELF).
Why? Password reuse! I can steal your session cookie (which allows me to pretend to your server that I am you) without HTTPS easily (see Firesheep). However if you add Javascript to your login page which, before sending, hashes your password (use SHA256, or even better, use SHA256, send them a public key you generated and then encrypt hashed the password with that, you cannot use a salt with this), and then sends the hashed/encrypted password to the server. REHASH the hash on your server with a salt and compare that to what is stored in your database (store the password like this:
(SHA256(SHA256(password)+salt))
(save the salt as plaintext in the database as well)). And send your password like this:
RSA_With_Public_Key(SHA256(password))
and check your password like this:
if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok
Because, IF someone is sniffing your client, they will be able to login as your client (session hijacking) but they will NEVER see the plaintext password (unless they alter your Javascript. However, a Starbucks hacker will probably not know how or be interested in this.) So they will gain access to your webapp, but not to their email/Facebook/etc. (for which your users will likely use the same password). (The email address will either be their login name or will be found in their profile/settings on your web app).
Actually I disagree that client side hashing is more secure in this case. I think it's less secure.
The entire point of storing a hash of the password in your database as opposed to the real password (or even an encrypted password) is that it is mathematically impossible to obtain the original password from a hash (although it is theoretically possible to obtain a colliding hash input, the difficulty of which depends on the security strength of the hashing algorithm). The possible attack vector here is that if a potential attacker somehow compromised your password storage database, he/she still would not be able to obtain the original passwords of your users.
If your authentication mechanism sends a hash of the password, then in the "security breach" scenario (i.e. attacker somehow got a copy of your password database), the attacker does not need to know the real password - they just send the hashed password that they obtained from the breach and hey presto, they have access to that user's account. This completely defeats the point of storing a hashed password in the first place!
The really secure way to do it is to send the client a one-time public key for them to encrypt the password, then you decrypt and re-hash it on the server-side.
By the way, this kind of question will probably get more expert responses over on Security StackExchange.
You're likely OK not to worry about this - as Dirk mentions even if you hash the passwords a malicious user could be on a network and see the hash get sent, and could simply send the same hash themselves.
It is slightly better, in that it prevents the malicious user from knowing what the password is, but since they can still log in (or potentially reconstruct the original password), that's not that helpful.
In general, if you're concerned about the safety of your user's passwords and data (and you should be!), you'll want to use a secure SSL server. If this isn't a concern for you for whatever reason you might as well not bother with hashing; it's just security through obscurity.
Edit Aug 2014: Google is pushing more and more strongly for websites to switch to HTTPS everywhere, because securing the communication itself is the only way to prevent network sniffing attacks. Attempts at obfuscating the data transmitted will only hinder, not stop, a dedicated attacker, and can give developers a dangerous false sense of security.
Recently both GitHub and Twitter announced that passwords where stored in internal logs. I've had this happen inadvertently in bug reports and other logs that found their way into splunk etc. For twitter if Trump's password was in there log it could be a big deal for an admin to "see", for other sites probably not as big of a deal as the administrators wouldn't have much use for it. Regardless as admins we don't like seeing the passwords do we.
So the question is really if the hashing should happen client side for security, but how can we protect the password before it ultimately gets hashed and compared by the server side so it doesn't get logged somehow.
Encryption is not a bad idea because the developers at least have to jump through some hoops, and if you find that passwords got into logs you can just change the encryption key, destroy the original, and that data becomes useless. Better yet rotate the keys nightly and it could reduce the windows greatly.
You could also hash a hash in your user record. The leaked passwords would be hashed plain text passwords. The server would store a hashed version of the hash. Sure the hash becomes the password, but unless you've got a photographic memory you are not going to remember a 60 char bcyrpt. Salt with the username. If you could gather something about the user during the login process (while not exposing that the user record exists ) you can salt with that as well creating a more robust hash that couldn't be shared between sites. No man in the middle would be able to just cut and paste the captured hash between sites.
Combine with a cookie that doesn't get submitted back to the server and you might be onto something. On first request submit a cookie to the client with a key, then make sure that cookie doesn't make its way back to the login service so little chance of it being logged. Store the key in a session store, and then delete it right after login occurs or when session expired... this requires state for you JWT guys, but maybe just use a nosql service for it.
So down the road an admin comes across one of these hashed and encrypted passwords in splunk or a bug reporting tool. It should be useless to them as they can't find the encryption key anymore, and even if they did they then have to brute force a hash. In addition the end user didn't send anything plaintext along the line so any man in the middle at least has a harder time of it and you can't just hop to another site and login.
Note that keeping passwords secure against third parties parties is not all there is to it.
As soon as privacy is involved (and when ever is it not, these days?) you don't want to know the password. You can't abuse or leak what you don't have, so both you and your clients can sleep better if you never ever see their clear-text passwords.
Therefore, hashing/encrypting client-side makes sense.
It depends, you can use client side hashing, but server side salt will not be possible.
have a look at the link
Password encryption at client side
This idea of client side hashing is to protect the user, not your site. As mentioned many times already, plain text or hashed passwords both have access to your site equally. You don't get a security benefit.
But your users actual, plain text, password should only be known by them. Knowing what they chose as a password is information that can be used against them on other sites and systems. You are being a customer-focused site by protecting them from having their password choice discovered by your server devs or by third parties.
I've been doing a lot of work on this recently, IRL there are two issues with client side hash / symmetric encryption with really kill the idea:
1. You have to get the salt back to the server SOMEHOW...and to encrypt it client side you'd need a password...which defeats the purpose.
2. You expose your hashing implementation (not a HUGE deal as most sites use one of 3 or 4 hashing algos) which makes the attack easier (as just need to try one rather than n).
What I eventually went to was asymmetric encryption on the client using OpenPGP.js or similar...
This relies on an imported or client side generated key on the client and the server sending it's public key. Only the client's public key may be sent back to the server.
This protects against MIM attacks and is as secure as the device (I currently store client's private key by default in localStore, it's a demo).
The MAJOR advantage of this is that I never have to have users data stored / even in memory unencrypted on my server / data store (and my server's private key is physically separate)
The basis of this was to provide people a way to communicate securely where HTTPS was restricted (e.g., Iran / N. Korea atc...) and also just a fun experiment.
I'm FAR from the first to think of this, http://www.mailvelope.com/ uses this
If someone can see the data in and out on your connection then authentication will not save you.
Instead I would do the following for super secret stuff.
Passwords prehashed on client side before sent to server.
(Server stores another hashed and salted value of that hash sent from the browser).
So a middle man attack could allow them to send the same hashed value to login as them, but the users password would not be known. This would stop them trying other services with the same credentials to login elsewhere.
Users data is encrypted on the browser side too.
Ah, so a middle man attack would get the encrypted data, but would not be able to decrypt it without the actual password used to login. (users password stored in the DOM on the browser when they logged in).
So the real user would see the decrypted contents but the middle man could not.
This also means any NSA or other agency would not be able to request you/company/hosting provider to decrypt this data as it would be impossible for them to do so as well.
Some small examples of both of these methods are on my blog
http://glynrob.com/javascript/client-side-hashing-and-encryption/
Consider this:-
Client sends request to server "I have a password to validate".
Server sends client a one-time only random string. R$
Client embeds the user's password in this string (based on any (variable) rules you wish to apply).
Client sends the string to the server and if password OK, server logs user in.
Should server receive another login request using R$, user is logged out and the account is frozen pending investigation.
Obviously all other (normal) security precautions would be taken.
The method that I have come up with is to use SHA-256 with multiple rounds and a random salt...
salt = generate random salt
hash = sha256(password)
for (i = 0 to rounds)
hash = sha256(hash + salt)
This encrypts the password in such a way that only the user knows what the password is. Both salt and hash are stored in the database. I have also implemented this on the client side using a server generated random string.
server_data = {
algorithm,
rounds,
salt,
string
}
hash = hash(server_data.algorithm, password)
for (i = 0 to server_data.rounds)
hash = hash(server_data.algorithm, hash + salt)
hash = hash(server_data.algorithm, hash + server_data.string)
In crypto class, we were taught that the attacker can know the algorithm, salt, rounds, etc.... But in this case, the actual hashed password is never sent. The server knows what the random string that it sent was, so the full hash is generated on the client, and the final piece is to hash that result with the random string. That's the result that's sent to the server. The result is effectively a one-time password that is useless on replay attacks. The user's password is never sent in the clear, and if the attacker gained the password hash, it would be useless to them because the server will not accept it in that form. The hacker MAY be able to compute a rainbow table for the salt and the number of rounds to try and brute force the password, but any sufficintly complex password using ASCII symbols 32-126 of at least 8 characters long will usually take a long time to crack...and that's for EACH password. The sites that I write for can have passwords up to 128 characters in length.
As for session hijacking, that risk can be reasonably mitigated by regenerating the session ID every 30 seconds or so. I also include a token that's embedded in the HTML of the page itself. On the server side, some of the client information such as the client's IP address and user agent string are hashed as well and stored in the user's session data.
So on each request, the server gets the cookie session ID and the token. The token is compared to what is in the session data. The other information such as the IP address and user agent are hashed and compared to what's in the session as well. If it all matches, then there's a very high probability that this is the real user and not an intruder.
The only way that I can see this happening is if the attacker has the embedded token, the same IP address, and the same user agent. It's all about probabilities. Besides, any time you are dealing with crypto, it can be hard to get right. So as others have said, don't do it yourself.
It's 2022 now. As hacker attacks are getting more sophisticated, luckily also have browser standards. The defacto transmission protocol is encrypted (https) and cross site scripting or replay attacks systematically are more difficult with content security policies and CORS.
I believe your time will be well spend familiarising yourself with these technologies.
I'm not a security expert and leave that in the hands of more capable engineers.

Is it a secure way to handle returning user in ember?

I am using ember to write a web ui for a site that requires user to log in. Suppose the browser has stored some cookie from last login of a user. Now the user visits the site again. So, is it a secure and common way for ember to log the user in automatically based on the cookie from the last visit? If so, what are the common ways to implement this? (I can't find anything from Google.) Furthermore, how do I create the cookie upon login? Is it a common way to just put a user id, password hash, and expiration in the cookie?
Additionally, any references related to this subject are greatly appreciated.
Edit 1
In light of Vohuman's answer, I think I can make my question a little more specific. Basically, what I want to know is a common and secure implementation to keep a user logged in, even when they close and reopen the browser. Namely, the life time is beyond the session scope. Take linkedin for example. If you are logged in and exit the browser. Then next time you revisit linkedin, you are still logged in automatically. Right now, what I can picture is a solution like the following.
When you first log in to the site, the server will return a cookie which includes an authentication hash token. Then next time when you revisit the site, the server will receive the hash token and thus authenticate your session.
So, is above flow basically what people usually do to keep a user logged in? If so, is the JSON Web Token (JWT) basically one way to construct the hash token I mentioned above? Additionally, assuming the connection is HTTPS, this approach seems secure to me. Is it not?
Edit 2
This article gives an interesting discussion regarding where to store the access token.
is it a secure and common way for ember to log the user in automatically based on the cookie from the last visit?
Yes and no. Security is a complex topic. Usually session cookies are used for authorizing users. This is actually the most used method of keeping the users logged in. If the user can't keep his credentials secure then any layers of security can be vulnerable.
For Single-page applications usually access tokens are used instead of cookies and sessions. The client sends the user credentials and server returns an access token. The token is encrypted and expirable and can be stored in localStorage or sessionStorage. Using JSON Web Tokens (JWT) standard is a popular method for implementing user authentication and authorization in web services. As an example, the Facebook Open Graph API uses access tokens.
JSON Web Token (JWT) is a compact, URL-safe means of representing
claims to be transferred between two parties. The claims in a JWT
are encoded as a JSON object that is used as the payload of a JSON
Web Signature (JWS) structure or as the plaintext of a JSON Web
Encryption (JWE) structure, enabling the claims to be digitally
signed or integrity protected with a Message Authentication Code
(MAC) and/or encrypted.
edit:
So, is above flow basically what people usually do to keep a user logged in?
For traditional websites, yes.
The whole point of using access tokens is keeping the web service/API stateless. This means that server doesn't have to store any cookies/sessions for authenticating and authorizing users. The stateless is one of the key factors of implementing web services that follow the REST paradigm. It's client that has to store the token and send it to the server (via the Authorization header or query parameters). The server doesn't store the token. Of course, you can store the tokens on the server if you want to add another layer of security, but it's not so common and not necessary. Storing the tokens on the server can also make your application vulnerable to database attacks and is not recommended.
If you want to make the process more secure you can decrease the validity time of access tokens (1 hour, 1 day or 1 week, it's up to you).
As for localStorage, is it secure?
localStorage data are stored separately for each origin (domain). A malicious user can only read the data if he/she has access to the user browser. You should make sure that your app doesn't have any XSS vulnerabilities so malicious users can't inject any scripts to your application. This is actually a different topic.

Are there any security concerns storing HTTP Basic authorization header in localStorage?

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.

User authentication in offline web apps

I'm building a web app that needs to work offline. The system is built to capture sales transactions. The bulk of the "offline" part is fairly straightforward -- I just need to store data locally and sync it when I'm back on the network. So far, so good.
The problem is with authentication. The app will run on a shared machine with a single OS user account. If I'm offline, how do I authenticate the user?
Users themselves do not have any private data that I will need to segregate (i.e., I don't have to protect them from each other on the client). I need to be able to validate their password so I can let different users login throughout the day even if the connection is down.
One approach I'm thinking of involves caching the password hashes on the client-side in an IndexedDB. Only a limited set of users will be allowed to log in from a specific shared machine, so I won't need to cache my whole password database locally. Assuming that I have a good password policy (complexity and expiry requirements) in place and the hashes themselves are secure (bcrypt), just how horrible of an idea is this?
Do I have any other options?
This is effectively how Windows (and other systems) work when the machine is not able to reach the domain controller (e.g., you take your work laptop onto the airplane and need to log into your laptop w/o connectivity). Your machine has written down a cache of your username|password pair and will let you in via those credentials even if it's offline.
I think generally speaking storing the username|password hashes is pretty safe, assuming you're hashing them reasonably (e.g., using a salt, using an IV, etc). One exposure you'll want to think through is having the hash file "escape." If this is sensitive data you'll want to be exceedingly careful -- and this may not even be acceptable, but if it's not super sensitive data then you're probably OK: with good hashing I think you should be reasonably (but certainly not completely) safe.
Maybe this is little unrelated, but I use this approach in my nodejs project.
When a user is authenticated by username and password, he/she is assigned a unique API key used only for this particular session.
Each user can have only one API key.
This API key is added to any request done to server, to authenticate the user.
When the user logs out, the API key is deleted. Also the API key can be purged on the server, that makes the user authenticate on the server one more time.
I can provide links to nodejs open source programs that use this approach if you interested.

How should I securely store passwords and use http auth in a chrome extension

I'm making a chrome extension that requires fetching an xml file from a secure server.
I'm currently using XMLHttpRequest() to make a call to the server
https://username:password#mydomain.com
which returns an xml object that I can parse and display. I want this extension to be available for more than just my hobby use, so it needs an options page to set and store the username and password.
How should I store the user password in chrome so that it is secure? chrome has a localStorage global for each extension that allows extension authors to store data, but it is stored in plain text. it doesn't allow extensions to access the 'remember my password' storage(with good reasons).
and is there a more secure way to do http auth? My current way of doing things requires passing the username/password in plain text in the url each time the function is called, even if the the authentication session hasn't expired.
The problem with asking for a key is that it means that you'll have to prompt each time at startup (if you store the key, you have the same problem). This may be an OK tradeoff if what you're protecting is especially sensitive.
In general, Chrome takes the philosophy of trusting the OS to protect the user's profile where this data is stored, so if you use local storage to store passwords, it's no different than what Chrome is doing today with password autofill, browser history, etc.
An idea: ask the user for a key, which you can use to symmetrically encrypt the values before putting them in localStorage. You could also generate a unique key per client based on certain unique aspects of his machine/browser/etc.

Categories

Resources