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.
Related
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.
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.
I'm developing an email client in PHP for IMAP accounts. Which would be the most secure way to store the account's password being able to retrieve it afterward to check emails?
I guess I should encrypt it somehow. However, how can I make sure that only my app will be able to decrypt it?
If you require login without any user interactions, then there is no secure solution. You'll need to rely on your OS's storage options which might prevent hostile unprivileged applications from reading the password.
If the user entering a single password on startup is fine, then you can encrypt the other passwords with symmetric encryption, and then use a KDF, such as scrypt or PBKDF2 to derive the master key from the password (and a salt).
Store the passwords in an encrypted file; require the decryption key when starting the app.
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).
The subject of how to store web site users passwords in tables has come up several times on SO and the general advice is to store a hash of the password, eventually an HMAC hash. This works fine for Basic authentication or for forms based authentication (really the same thing). My problem is that I must provide also Digest authentication, aimed at the automated tools connecting to my service. I've been looking at this problem and as I see it, the only hash I can store is the HA1 part of the Digest: the hash of username : realm : password. This way I can validated both Basic/forms and Digest.
My problem is that I don't see any benefit in doing so. Now indeed an attacker cannot use Basic or forms based authentication if he gets hold of my password table (since he only has the hashed value and he needs to send the clear password), but nothing prevents him from using Digest authentication and give a valid response to my service challenge: he simply starts from the pre-computed HA1 from the table and continues the crafting of the response from there (ie. the same thing I'd do to validate a user on the back-end).
Am I missing something? Does the addition of Digest requirement basically makes the storing of hashed passwords a no-op from security pov, an obfuscation at best?
The reason I am using pre-computed hashes is not protection against attacks, but to secure users privacy.
Attacker can indeed authenticate, but he cannot (easily) see password of my precious users and compromise other services they are using etc.