I need to store a sensible info in a database (clients passwords). Is there a common practice? The information should be accessible by various users. Think about service company that should make maintenance of clients systems.
I'm thinking about using AES encryption. All the information is encrypted with the same main key. For every user this main key is encrypted with the user's password used as the key and stored separately. During login and authentication the main key is decrypted and saved in a session. Later the key is used to decrypt clients info. Is it a good practice?
Thanks
P.S.: Yes, I know that it's better not to use passwords, but it's not me to decide the way to access client's servers.
Related
Are there any packages, frameworks, or services to do client-side encryption of user data in Flutter, using firebase as a server?
I hope to build an app that handles some of a user's personal financial information and so I want no one else, including me, to be able to access it. Firebase allows a Dev to see the unencrypted database so I need to do the encryption on the client-side.
I think this will probably have to involve a client-side symmetric key used for encrypting and decrypting the user data.
My worry is how to store this key.
(1) Randomly generated key stored locally - doesn't allow the user to switch between devices and is lost if the device is lost
(2) Store it in a Google Drive - requires the user to have a Google account. (Advocated by this article from HackerMoon
(3) Generate it deterministically from a salted hash of the user's password (stored locally) - lost if the user forgets or changes their password.
(4) Allow the user to choose between a subset of the above
My question is similar to this one How to encrypt user data in Firebase but it covers situations were data is transferred between users and hence uses public key cryptography.
Questions:
What is the best way to encrypt user-data for a firebase db?
And if it is to use a symmetric key, what is the best way to generate and store this key so the user doesn't risk losing access to their data?
This one appeared to be the best solution for my case: flutter_secure_storage. It stores the data in an app specific container within the official key stores of iOS and Android
Can you explain me the exact reasons and benefits of using hashes of password instead of the passwords themselves?
Because parcticly if you got hash of user you can authenticate as that user, and anyway the password is invisible.
It's more secure to store a hash of a password rather than a password itself (e.g. in keytab).
Kerberos only transfers over network encrypted Authenticator with its own copy of a secret key. Authenticator contains unique information about the client (for example, client name, client realm, the time on the client, and so forth). Each Authenticator is unique, because of the time information it contains.
So information transferred over network can't be reused (replayed later by an attacker), as Authenticator is unique and depends on time.
Hope this helps. With Kerberos you don't have password stored nor transferred over network. Which makes it more secure.
I am developing an app which uses several API services, the API requires that I provide username and password for API transactions, unfortunately no API token :-( in-order to automate I need to store username passwords somewhere, preferably database, I cannot use hashing because I need to send the username/password to authenticate and process API request, hence I am wondering how to go about it.
If I use Zend\Crypt to encrypt and store the password in database and decrypt whenever required, would this be enough for security? is there something else I must consider?
Looking for pointers.
PS: I am using ZendFramework2 with Doctrine/MySQL for the app.
Usually you would use a token mechanism (like OAuth). If that's not possible, one would use TLS/SSL client authentication.
However, if you rely on plain passwords (on the application-level, I still guess the username/password tupel is transmitted over a secure connection!) and you want to store them encrypted, you have to think of a meaningful mechanism to get an encryption key for your scenario. Just generating an encryption key and storing it on the same machine in plain does not provide more security.
Without more information on your scenario it is hard to make a suitable suggestion.
I know that usernames and passwords shouldn't be stored in the database in a reversible form, but I need these credentials for accessing a REST-API over HTTP Basic Auth. Would it be secure enough to store an encryption key on the servers hard drive and use it to en-/decrypt the stored passwords or is there any other method to securely store passwords for REST-API's in a database.
Thanks in advance
Consider the following interaction:
A user stores their username and password on a web server. For the sake of security, the server records a hash of the password plus some unique salt.
While the user is using a client application, it makes a request to the server submitting their username and a hash of the password plus some other unique salt.
So you have the following information on the server and need to know whether or not the request is authentic:
The server's salt
The server's hashed password
The client's salt
The client's hashed password
Again ... client sends: clientSalt + MD5(clientSalt + password). Server has serverSalt + MD5(serverSalt + password). I don't want to know the password, I just want to know if the hashes were calculated from the same password.
Without knowing the password that was hashed, is there any way to verify that both hashes are of the same password?
My goal is to allow some form of secure authentication in a client-server environment without ever exchanging the actual password over the wire. This is just one idea I've had, but I don't even know if it's possible.
That would require unhashing the password, which is not possible. If the server receives: salt, md5sum, it can't see what went into the md5sum.
A challenge-response protocol would work instead. The server should generate a random value nonce and send it to the client. The client calculates md5(md5(password) | nonce)) and returns it to the server. The server verifies by checking md5(storedpassword | nonce).
No, you can't do this.
Once you add a salt into the mix it becomes practically impossible to compare hashes. (To do so would require "un-hashing" those hashes somehow before comparing the "un-hashed" data.)
Challenge-response authentication is probably the way to go, possibly using Kerberos, depending on your tradeoffs. One of the tradeoffs being the possibility for attackers controlling the clients to use compromised hashes to authenticate themselves.
Don't invent your own cryptographic protocols. Use one that is well-known and well tested. If possible, use an existing (vetted) implementation.
My goal is to allow some form of secure authentication in a client-server environment without ever exchanging the actual password over the wire. This is just one idea I've had, but I don't even know if it's possible.
For this, I advise looking into Kerberos: Official Site and Wikipedia
It's impossible. If you don't store password on the server, user must provide it.
OR
If you store password on the server, user can provide hash calculated using requested salt.
You will not be able to verify the hash with this setup.
If you don't want someone to see the password go over the wire, SSL is the easier way.
If you don't want to use SSL, you could check out SRP.
Additionnally: don't use MD5+Salt to store your password, use key strengthening functions like bcrypt or scrypt.