What is the most secure option to store passwords for TYPO3 frontend and backend users ? Which encryption algorithm is used ?
There is no encryption of passwords. The passwords are hashed, the mandatory extension "saltedpasswords" takes care of that and provides multiple salted hash algorithms.
The default hashing algorithm configured for both frontend users and backend users is PBKDF2 for new instances, which is the NIST recommended way to store passwords in a FIPS compliant way.
Other hash algorithms can be configured, for instance blowfish and phpass are available by default, too. Own hash algorithms can be added and used if needed.
Related
I'm building a system that connects to a third party api, and I have to store passwords for each of our users connected to that api. I need to make sure that the passwords are stored securely, so I don't want to trust the user's password as an encryption key. But I also need to make sure that we need the user to authenticate the use of this password, by entering their password.
I had the idea of creating a key by combining the user's id and password with a secret key on the server (just by concatenating them all). I then use crypto's createCipher with aes256 and the new generated key to encrypt the third party password and send it off to storage.
I noticed the text in the createCipher documentation that says this:
In line with OpenSSL's recommendation to use pbkdf2 instead of EVP_BytesToKey it is recommended that developers derive a key and IV on their own using crypto.pbkdf2() and to use crypto.createCipheriv() to create the Cipher object.
And I read up about IVs and the attacks they are meant to prevent (still pretty confused about how that works, especially with my use case) but I think that since this will technically be using a different key every time, that will be a non-issue.
Is this kosher? Is there some vulnerability of this system that I'm missing?
I do not understand some concepts of storing/processing passwords.
For example, our site has a public api for mobile application(iOS, Android, etc) with provided authentication.
No doubdt, we must not store raw passwords in the database and we must not send raw passwords between client and server, so we use hashes and salt.
This way, we encrypt passwords on client and send hashes to server. But, what if a "black hat" steals password hash and authenticates with it to server api?
Should I hash passwords on client, send hashes, then hash them again on server?
What is the common solution of this problem?
Great thanks in advance.
You can use SSL to protect communication channel between client and server, and send password unencryped.
Second approach - to store hashed passwords (without salt) in server, and when authenticate - get random token from server (that will expire in some minutes), calculate hash from client password and use calculated hash to encode received token. Then send encoded token to server. Server does same operation but use hash stored in database instead calculating it from password. This approach has cons - needs to store password raw or hashed without salt. Or send salt to client with token.
But, what if a "black hat" steals password hash and authenticates with it to server api?
This problem is solved by using tokens that will expire after usage.
Do a lightweight hash client side (no salt), then rehash the hash (with unique salt) server side. Store the salt and (doubly) hashed password.
The server side hash should also use something like pbkdf2 or scrypt that can perform thousands of hashing iterations to deliberately slow down the hashing process. This helps prevent brute force attacks of the hashes by slowing down the attack process.
Hello anyone knows how security is provided to text password in Google or in any website. In my web-app i am encrypting password using AES algo. Should i need provide more security? If yes what kind of security is needed? How text passwords are managed/ made secure by Google or any web site?
Do not encrypt passwords.
Instead, you should hash passwords using a slow salted hash, preferably bcrypt or scrypt.
You should secure your forms (also username and password fields in Login or Registration forms in HTTP transactions) and also the important data(s) in your database by hashing them with SHA-1 or MD5 algorithm (with salt)
For your login and registration forms you should use SSL connection in order to prevent man-in-the-middle and also sniffing attacks.
I am researching how to implement a persistent "remember me" type cookie for a site. I was just wondering is using a GUID for a security token as secure an an md5 hash of username and password?
A GUID is more "secure", because there's no possibility of information disclosure in a random identifier. Otherwise, were the username to be known, the password could be extracted using a per-username rainbow table or a concerted attack since you did not add salt before hashing. NB: MD5 is a rather weak hash at this point.
Long story short, if you don't need to store private information in cookies for really really good reasons, don't. Use a random token instead.
So I need to be able to actually decrypt the password because some old websites don't use OAuth and I need to have some of my users have access to them through there API. Therefore one way hashing does not work for me. I have been told that the best way to store the passwords with AES and using the salted hash of the passwords as the key. How do I store all the keys and where do I store the salt? Basically how would I exactly implement this.
Thank You
If I understand you correctly you have the following situation. Users log in to your system with a username and password. Your system then needs to impersonate these users by logging into another system that you do not control using the user's username and password for that system which they have given to you.
If that is correct, then it might be reasonable to encrypt their credentials for the other websites using AES. In this case, I would not store the key used to encrypt those crendentials. The password that the user uses to access your system should be used as the key, and it should not be stored anywhere. In this way, you have a chance of protecting your users privacy (depending on the design of the rest of the system, of course).
Since you are encrypting rather than hashing, and the encryption key would be differnet for each user, salting is not necessary.
Also, I would encrypt the full credentials, not just the passwords. Your users are showing an incredible amount of trust by giving you their credentials in the first place, so I would do everything possible to justify that trust!
Your approach is essentially to use AES as a hash function but this will not allow you to decrypt the passwords (short of brute force or some yet-to-be-discovered vulnerability).
You might want to consider asymetric key encryption instead (e.g. RSA). You'll need to encrypt the passwords with the public key of each person you expect would need to decrypt it (which would include the user).