I'm developing a static website that accesses a web service for some data which uses basic HTTP authentication. I'd like to ask the user for the credentials once, and use those credentials in multiple pages of the static site.
I'm trying to figure out where to store the password with reasonable security. Cookies and local storage are inherently insecure, even if I encrypt the data (the key would still be in the Javascript code). Session variables (i.e. sessvars) seem to be even worse.
I really would like to avoid using a server for this since I don't need a server for anything else.
The only thing I could come up with is building the entire site as a single HTML page and store the password in a closured variable. Even if it's safe enough (which I doubt), it'll still require the user to enter the password each time they visit the page and therefore not ideal.
Any ideas?
Related
I am trying to figure out how to build a basic login/signup feature for my React application. So I am considering creating a HoC/parent class that does things such as logging in and checking if a user logged in.
SO now I have come to you to figure out the best way to store whether a user is logged in or not. What I saw is using localStorage. But that could be accessed by anyone really right so I can just store a flag saying isLoggedIn or something? Would I have to encrypt some token such as a username.password and then on every page load do a call to the DB? That seems a little much. Or have a missunderstood something?
You can use JSON Web Tokens (JWT).
When the user logs in, call say /login of your backend to check the password against your database. If successful, issue a JWT containing the username and its role, for instance (not the password).
You can always tell then if the user is logged in by verifying directly with Javascript the cryptographic signature of the token (if the readable content, such as the user name, has been altered, then the signature will not match anymore). This way you don't need to interrogate the database until the token expires.
What I saw is using localStorage. But that could be accessed by anyone really right
No. It also has the advantage over cookies that it is accessible only from the same domain. In principle there is a way that your token gets stolen (e.g. XSS attacks, or copied from dev tools on your laptop when you are away), but the expiration time that you will add to it will make it valid for only a few hours.
I am working at writing a small website that should use an authentication system that requires me to store a token. Storing it in the localStorage would be for me the most convenient option at this stage, but as I understand, this is potentially vulnerable to XSS attacks. Now, the security requirements aren't very strict (no especially sensitive data would be exposed by a successful attack, the login is just used to keep track of who does what while on site), and there should be no user-generated content on the website (no comments or such), and anyway it's all passing through Angular.js. Does that sound like it's reasonably safe to use the localStorage alone, or should I still look into using it next to cookies for added security? Thanks!
If you are not displaying any user content (not even user login to display who is logged in) standard XSS attacks should not be a problem for you.
Hovewer,make sure you are do not have even the simpliest user generated content. If you are displaying some data from some data source this is also something that should not be trusted. If you are for example displaying user login, you should make sure that, login is properly sanitized prior to usage. User login could contain attack code. Angular.js can help you there with the usage of $sanitize. Also be aware that there is always risk of a self-xss.
LocalStorage is good place to use. Hovewer, you should verify that token is safe to use - it may be expired, or invalidated (e.g when your Angular.js application boots, you could verify token by some call to the API).
I need to access an api which requires http authentification on a per user basis using a jquery mobile api.
I plan to make the app available as a website as well as packaging it in Cordova for various devices.
If I have a login form which captures the username and password and store this as a javascript variable, is there any way this data could be exposed?
If so, what's the best alternative to handle storing the users authentification details? I am reticent to build an intermediary server if I don't have to.
Many Thanks. :D
I would suggest not storing the username or password in the localStorage, but instead to store an access token. Access tokens can be updated and changed frequently, it also doesn't reveal who the user is or what their hashed password is.
Besides iOS Keychain or if you're coding it for a non-iPhone device for added security you can:
Change the access token at each login and each time the app is used
Store the device ID in the server database (see http://docs.phonegap.com/en/2.2.0/cordova_device_device.md.html#device.uuid)
Clear the localStorage and request a new login if the access token or device ID doesn't match the data stored in the database
Make sure you don't store the device ID in the localStorage.
For added security you can also store the user's IP address in the database and check (server side) if the IP address matches, but this might too much since the user would have to login every time they connect to the internet in a new location or if their IP address changes.
Storing the IP address in the server database then checking if it matches (server side) would probably be the safest since it wouldn't matter if someone got hold of the localStorage data.
So I understand you don't control the backend you log in to? If you do, I would be more inclined to send username/password once, and then store some access token that will allow you subsequent access.
If you don't control the backend, you're stuck with storing username/password. I would say, setting them in localStorage is as safe as it gets (which is, admittedly, not very safe. Then again, if your login doesn't happen on HTTPS, I would be more worried about passwords leaking there than from the device itself). You could make the passwords harder to find, not call the variables "username/password", encrypt them in javascript, obfuscate your code. But in the end, they can always be retrieved without too much effort with the right access to the device.
After packaging as native app, you have more options, e.g. iOS keychain: http://shazronatadobe.wordpress.com/2010/11/06/ios-keychain-plugin-for-phonegap/
I made fire fox add-on using java script. I want to give password protection to this add-on. Where can I store the user password permanently ? How can I do this?
The best solution would be to store on an external storage. Just like websites. You send the authentication data, server checks for user and returns true or false. There are a few problems with this. If you want to restrict parts of add-on for non-registred users, that's not possible. The whole code is available to the user and he can modify it.
If you create a website specific add/on search for a data (most likely in the cookies and preferences of the website) that is a secret, unpredictable, unique and uniform for a single user. You can hash that and use it as a password. Along with the username of that specific website. This way you can avoid registration.
Server communication trough HTTP is not too secure, but hey, most websites still use it.
If you don't have an external server available, you can use local storages like a SQLite, or i you have a single password you can use the preferences which are also available under about:config. But these are far from permanent. It's there until the user reinstall operating system, which unfortunately is quite common.
If you want closed source to hide storage mode, hash generating or something like that XP-COM components might help you but I don't recommend because it's really hard to maintain (all versions on all platforms).
If the password is required to authenticate the user to a server then you should use nsILoginManager to store it. The password will be stored encrypted on disk if the user defines a master password. If you want to protect the extension's user interface from the user then it doesn't matter where you store the password - this kind of protection works only against inexperienced users. E.g. you can use Preferences to store it.
I want to add integration with a third-party service to a web application (developed in HTML and Javascript) which targets Android / iOS (and later Windows Phone). Thus I have access to all "modern" features. This third-party service needs credentials and is controlled via GET-Parameters.
For example, a request url could look like "http://www.example.org/foo?username=user&password=1234".
Changing the third-party service to accept hashed passwords is no option as I have no access to it.
As the user does not want to type in his username and password every time he uses the service or starts the application, I want to save his credentials somehow.
Now I wonder, what's the best way to do so.
I know that real "security" is an illusion here but I do not want to expose the credentials to unnecessary risks by saving them the wrong way.
I already thought about several possible ways
Plain Cookies: The most
straightforward way - is it "secure"
enough in this scenario?
DOM-Storage:
Any differences to cookies in this
relationship?
Encrypted Cookies: The
credentials would be encrypted, but
you could easily find out the key
when looking at the source code of
the page or debugging it.
Which one should I choose? Are there any better ways?
Is bothering with encrpytion actually worth it when it can be cracked that easily?
All the ways are bad and insecure. So is sending username and password as a get param - you even run this over https?
The way to do this usually is to not store the username/password at all, but a GUID/hash that identifies the users session, and then let that session be persisted.
That way, even if somebody else gets access to the session, they won't have the username/password. As part of this, people cannot change the password unless they supply the existing.
Connect to and authenticate with the 3rd party service through a backend proxy if it absolutely needs to have username/password sent.