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/
Related
I'm developing a reactjs based application. I want to limit the login from multiple devices at one time to an account. So I need to have an ID that is unique and fixed on device.
I also want the user to stay logged in on one device, so I can not use IP address.
Also, I've already limited access from several browsers.
Thanks a lot. Also, sorry for my English.
This check can't be implemented on client side of the application.
On the server end, you can get IP address from requested payload. You can store the IP address against the session in In-memory databases like redis or memcache. Now, create an intermediate check at login controller where you can block the user if he/she has logged in more than certain number of IP addresses.
I'm building an app and an API endpoint using PHP(I know what you thinking!). My issue is that if I ask user for username and password on opening the app for the first time, since I can't store these details locally because they could be compromised. I'd send these through Post request to server then generate a token depending on whether the user is the right one. After getting response I must store this token locally right?
Yes!. there's expiration for the token. After the token is expired, I don't want to ask user for their name and password but want to access API still authenticating as that user. How will I do this?
If I use Oauth it's still the same procedure right? I should store something locally. won't that be compromised? I'm very confused.
How does other apps work. I'm sure they doing something in the background. They ask us for credentials only once and all subsequent API calls will be secured. Won't the token expire in that case or what?
Can i secure API calls without storing anything locally? I don't want API to be accessed from anywhere else but app.
Use android SharedPreferences. It should be very secure unless you deliberately expose it e.g. its accessible via an exported content provider missing the (android:exported="false") in the manifest. You can also use sqlite but there is no point of using a db table for one or two rows of data.You can also encrypt the user name and password to add one more security layer to protect rooted users.
Furthermore to protect the data in the network you should use ssl in the backend so no one can sniff the credentials.
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 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.