I'm building the authentication with openid-oauth2. I managed to gather access_token, identity_token from auth server. I want to store those values and use those values in each api call. I have several options as I searched.
I can use secure storage package which can hash the access_token and I can read that value to perform api call.
I can use Inherited Widget. Create a inherited widget on top of my application and read from the inherited widget.
I can use Singleton. Simply create a class which will act as singleton class and store my access_token inside that class.
I can use Shared preferances.
Of course the 2., 3. and 4. options are not secure. However, I don't know whether store those values securely is necessary.
What is the best practice in flutter to store those values?
I'd suggest your first choice flutter_secure_storage which I already use to store token. Its perfect choice for the use case.
A Flutter plugin to store data in secure storage:
Keychain is used for iOS
AES encryption is used for Android. AES
secret key is encrypted with RSA and RSA key is stored in KeyStore
Related
I need to store login credentials with electron js because it doesnt save them like all browsers. I have seen a lot of questions like this, but I never found a solution. I have seen in the electron docs about the safeStorage feature. is the it safe enough/good enough to store login credentials on the client side? if not what other tools are available to do that? I have heard about keytar but is it good?
The safeStorage api in electron exposes OS-level encryption/decryption using current user's secret key - please refer to electron source and chromium's os_crypt. On windows it utilizes DPAPI while on *nixes it uses whatever password manager the OS has as the documentation suggested.
is the it safe enough/good enough to store login credentials on the client side?
Depends, you should define "secure" first.
Ask yourself, should the same user allowed to read whatever value inside the encrypted text? A tech-literate person might write his own tools to decrypt things you store using that API you are out of luck. See this QA for further discussion.
if not what other tools are available to do that?
There are a lot of tools (and encryption algorithm) to encrypt stuff in nodejs. However, you have to remember an encryption require you to have a key of some sort and the key need to be protected too. Hence, try your best to avoid egg-chicken problem with your key of keys.
OS-based key storage avoids the key of keys problem by storing the "master key" in a way that only accessible using its API. At runtime, you can't retrieve the key at all, you just send a set of bytes for the OS to magically encrypt/decrypt. While at rest, the OS may rely on secure storage such as TPM (Trusted Platform Module).
is electron's safeStorage for passwords and login credentials?
Depends, if you are running a web service it is preferrable to not doing so. You should never dump end user's user name/password directly on a storage that you can't guarantee its safety by yourself (e.g. your server). You should, put an identifier which can be revoked or may expire at later date - token or cookies.
Imagine the trouble when your end user device get stolen. If it's a token/cookie, they can request you to revoke their access from that device - similar to "Log me out from all other device."
However, if its an in-situ application that authenticates to itself then its a fair game - though keep in mind about the first point. Its all down to your security model.
I've been looking at implementing JWT for the first time using jsonwebtoken (https://github.com/auth0/node-jsonwebtoken). For that, I need a secret value.
Is there a recommended command, or site, to generate a sufficiently good one?
I found this page (https://security.stackexchange.com/questions/95972/what-are-requirements-for-hmac-secret-key) which goes into detail about how long a secret should be (the answer seems to be a 256-bit), but where do you get one from? :)
Else it seems the other option would be to use a public/private key pair. They seem to prefer that approach on this guide I found: https://medium.com/#siddharthac6/json-web-token-jwt-the-right-way-of-implementing-with-node-js-65b8915d550e since that guy says he started off using a string and then switched to using a key pair. However the complication is this will be running on Lambda so I would ideally like the secrets (string or key) to be in environment variables. Not kept as files. But if you put a certificate in an environment variable, I wonder if AWS will strip out newlines and so screw it up when Node tries to work with it. So I'm thinking a secret string would be simpler - as long as it is sufficiently strong.
Thanks!
This is what I did when implementing HapiJS with JWT2. I generated a key based on the documentation they provided. According to their repo, this is one of the simplest ways to generate a secure key to sign against for JWT.
node -e "console.log(require('crypto').randomBytes(256).toString('base64'));"
I don't think you have to use asymmetric key authentication with public/private keys for JWT. In simplest forms, when a user logs into your system, they are given a hash of user data. On the client side, you provide that hash in the authorization header with each request. The server will check the hash to verify integrity. Since you have the key that you hashed against, it's highly unlikely that they will be able to create a forged hash.
Check out this link to the GitHub issue where they discuss generating keys for Hapi-auth-JWT2.
I am using Rijndael Managed class for encrypting some data through my code. I am also generating Key and IV for the same using a fixed password and salt by Rfc2898DeriveBytes class.
But I am not storing these(key,IV, password, Salt) explicitly in DB, instead, I generate them in code onetime , store them in session variables and use them for encryption and decyption while the application is running. So, everything is in my compiled dll. Is that practice safe? I do not want to defeat the sole purpose of encryption.
No, this is not a good key management practice, but neither is storing them in your application's database.
Ideally, keys should be stored in a hardware security module where they can't be extracted. However, since that is not generally an option for most applications, on Windows (which I'm assuming is you're using, given that this is a .NET app) you have DPAPI which you can use to store the keys, or for the simplest option you could use an encrypted config section to protect them.
As an aside, I'd probably reconsider the use of the password and KDF. When you have an application that doesn't require a user to remember and type in the password such as a web application that is using the key independently of the users, it's generally a better practice to simply generate a strong random key, and store that directly rather than a password and salt, and have to derive the key.
I am encrypting the communication with the server in my blackberry app. I am using the RC4 encryption which needs a key to be provided. What's the best place to hide this key inside the application ? First of all is application a good place to store the key and second, is it safe to use a String variable to store the key ? Any suggestions/tips ?
That depends on what your definition of 'safe' is. If you put the key in plain text anywhere in the application there are people with the skills to find it and use it to compromise your application communications. Whether that happens or not will depend on how attractive doing that would be.
You could place it in the device keystore, but you would still have to distribute the key somehow.
Why aren't you using SSL/TLS?
Assuming I have a ASP.NET MVC 3 application that runs in a web farm where each web server belongs to a workgroup (as appose to a domain with shared accounts). The web farm is also auto scalable, meaning that the number of instances are dependent on the load. Sensitive data is encrypted and decrypted when stored/retrieved from the database. The symmetric and asymmetric keys are stored on each machine and protected with ACL and encrypted using DAPI (using the machine key).
For compliance and security reasons it is required that keys be rotated on a regular interval. How would you design/modify the system to automatically rotate keys at a regular interval without bringing the system offline? Assume that there are an arbitrary number of tables each with an arbitrary number of columns that are encrypted using the keys.
Many Q&A are related to which algorithms to use and how to secure the keys, however few actually address how to design and implement an application that would allow those keys were to be rotated, especially in a dynamic environment (autoscaling environment) sharing a database.
Having multiple keys in your system
When having multiple encodings (or encryption schemes, keys) what you usually want to do first is introduce some kind of versioning scheme as you need to know which key has been used for this particular piece of data. You have several choices for this:
Timestamps: Save the timestamp the data has been encrypted with the data. Then divide time into intervals of some length where the same key is used.
Version numbers: You can also simply assign increasing version numbers.
Key fingerprint: Store they key's fingerprint with the data
In every case, you need to store all keys that are currently in use to be able to decrypt data. When reading data, just look up the key matching your version identifier and decrypt. When writing, use the currently active key and store the encrypted data + your version identifier. You can retire (aka delete) a key when you are sure there is no data encrypted with this key in your database.
Deploying new keys
Whenever you roll over to a new key, this key has to be generated and deployed. You can do this in a central fashion or use some distributed key agreement protocol.
Re-encrypt data
If you need to re-encrypt data, you can do it in two ways:
Background process: Having a background process that just retrieves N data items with an old versioning identifier, decrypts and re-encrypts it and stores the result. Sleep a bit between runs to not overload your system.
Update on access: Whenever you read data and you notice that it has an old versioning identifier, re-encrypt with the current key and store the result. This might not re-encrypt everything depending on your data-access pattern, so an additional background process might be necessary.
Asymmetric crypto
If you are using asymmetric crypto (I guess for example for storing credit card numbers, webservers only having the public key to encrypt and the payment processor having the private key to decrypt) it gets a bit tricky, since only the machines with the private keys can re-encrypt data. All other aspects are the same.
Google's Keyczar provides such a framework, but there ins't a .Net version.
Maybe you could wrap the C++ version in a .Net wrapper ?