im have designed a complete mobile app.
The user has to login with their credientails in order to access the app. However, I am unsure where to store the credentials once he/she signs in. I will be reusing the username throughout different screens in the app. Where can I store them and how can i access them? is there such thing as a global variable for instance?
Also, say a user logged in the first time. I want the user to be able to shut down the app. Once the user comes back, he/she should not be asked to reenter their credentials. How can that be done?
Thanks
Luckily, all these infos are available on the official React Native docs.
https://reactnative.dev/docs/security#storing-sensitive-info
For persisted user data, choose the right type of storage based on its sensitivity. As your app is used, you’ll often find the need to save data on the device, whether to support your app being used offline, cut down on network requests or save your user’s access token between sessions so they wouldn’t have to re-authenticate each time they use the app.
The usual way to achieve that is by using the secure storage of each platform.
iOS - Keychain Services
Keychain Services allows you to securely store small chunks of sensitive info for the user. This is an ideal place to store certificates, tokens, passwords, and any other sensitive information that doesn’t belong in Async Storage.
Android - Secure Shared Preferences
Shared Preferences is the Android equivalent for a persistent key-value data store. Data in Shared Preferences is not encrypted by default, but Encrypted Shared Preferences wraps the Shared Preferences class for Android, and automatically encrypts keys and values.
Android - Keystore
The Android Keystore system lets you store cryptographic keys in a container to make it more difficult to extract from the device.
In order to use iOS Keychain services or Android Secure Shared Preferences, you can either write a bridge yourself or use a library which wraps them for you and provides a unified API at your own risk. Some libraries to consider:
expo-secure-store
react-native-keychain
react-native-sensitive-info - secure for iOS, but uses Android Shared
Preferences for Android (which is not secure by default). There is
however a branch that uses Android Keystore.
redux-persist-sensitive-storage - wraps react-native-sensitive-info
for Redux.
More on that here: https://reactnative.dev/docs/security#secure-storage
Related
I would like to use WebAuthn to securely store and retrieve some senstive information on mobile Safari.
I mention Safari specifically because it is my main target browser and the storage and retrieval of password credentials is unsupported there. Ideally, I would like to use the device biometric sensors on iOS and as I understand it, it's only possible using WebAuthn and a public key credential.
I don't want to have to create a server based service that has to store this sensitive information and to evaluate credential signatures. I would like to implement entirely on the client side.
Is there any straightforward or workaround solution to achieve this?
A passkey is a credential used for phishing-resistant authentication. It is not designed to store arbitrary information nor is WebAuthn designed to store or retrieve arbitrary information.
I have a Cordova app on iOS that currently stores data using localStorage for offline use. This data can be viewed in plain text if the user has root access (either on a jailbroken phone or with sideloaded apps).
I would like to secure this data. Ideally I would just store this in KeyChain but it is disabled on the clients devices. I've thought about encrypting the data but it will be easy to reverse engineer any javascript implementation.
Any suggestions? Thanks.
I have a application free and pro version, in this application user can store the values in localstorage values. But main problem is, if the user buy the paid version, they need some localstroage values from free version.
I think, we can access that application localstorage values using 64bit API key. But I can not search like that.
I can done it through user login and upload the localstorage value to my database and etc. But my application don't have the login process.
If the free and paid versions are separate android applications then localStorage cannot be shared as it is application-contained
I want to create a client-side (server-less) application using the AWS SDK for JavaScript in the Browser. All intended users of the tool have individual IAM users and access to the AWS Web Console.
I want all API calls to be executed in the context of individual IAM users, so they are subject to each user's individual permissions, and so that I can see who did what in CloudTrail.
Since no kind of browser local storage should be trusted with persistent credentials, I cannot simply let the user enter his secret access key once and keep it.
However I guess I could request the user's access key id and secret access key on the beginning of each session, then call STS GetSessionToken with it, and only store the resulting temporary security credentials in the session storage and use that for all following SDK usage.
Of course it would be much nicer for users to be able to log in with their IAM user and password instead of their long and cryptic access key (think of mobile devices...).
Is there any kind of federated login option for IAM users (redirecting them to the AWS IAM login page), or a way to call the STS API with username and password?
Ideally, what you want is login via IAM user/password combination. As far as I am aware (and also see this) there is no standard way of doing this.
In one of my projects, I've simulated online login using HTTP client. If you can get the session token with that, that could work for you. But it does not support MFA, and is relying on the internals of the AWS authentication implementation which might change without warnings.
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.