A third-party application states that TDE is used for encrypting the password database.
I don't know how appropriate this is for password storage as surely a decryption key still exists despite the fact that it is itself encrypted. The third-party state that internal staff do not have access to the passwords but I'm struggling to understand how that can be true as my understanding of encryption would not agree.
I've spent some time googling and whilst i understand the concept of TDE at a high-level, I am not convinced it's appropriate for storing customer passwords and claiming that no internal staff member can access these passwords.
Any comment or clarification would be much appreciated!
Related
I hear about all these websites getting hacked with sql injections and stuff. What's preventing them from encrypting the hashes with a 32 character string? If I were a hacker and I managed to get the database and I came across encrypted hashes I would not be able to do anything with the database as I do not know the encryption algorithm and the key.
As long as the key being stored securly everyones account would be safe.
Your idea of encrypting the hashes will indeed improve the security of the users password, but you should understand what exactly you are solving with this measure and what not.
First and most important, encryption on passwords is usually frowned upon, because it is a weak protection. If an attacker has the key, he can instantly discover all passwords. So the encryption does not relieve you from properly hash passwords with a slow algorithm like BCrypt, SCrypt, PBKDF2 or Argon2.
But your question was about encrypting the hashes. There is a case where even properly hashed and salted passwords can be recovered easily. If the user has choosen a very weak password, a dictionary attack will reveal them very fast anyway. If the hashes are encrypted though, the attacker needs the key, before he can start with the dictionary. This leads us to the following situation:
Encrypting the hashes will protect weak passwords, as long as the key stays secret. This is always the case when the attacker has no privileges on the server, examples are SQL-injection, disregarded servers, backups, ... I tried to describe this at the end of my tutorial about safely storing passwords.
This has puzzled me for a while now. I don't have a broad understanding on encryption, but I understand the principle.
For the sake of an example, let's assume I have a program whose sole purpose is to post a random user's input to my private facebook profile. Now to do this, the program must have my login information to facebook (if this is not the case, assume another third-party application). This information, or credentials, must be stored somewhere, since the program's post method would be done without administration.
I know it is a bad policy to store the login credentials in the code as plain strings, as the compiled code can be decompiled and my credentials would be readable. The recommended solution is to store them in a separate file, encrypted.
As far as I understand, the encryption / decryption needs a key that also needs to be stored somewhere. Can't this key and the encryption algorithm be read from the decompiled code and used to decrypt the credentials?
Is the benefit of storing the credentials encrypted based on the extra step on decompile-decrypt, or have I drastically misunderstood something?
There are 2 ways one could check supplied credentials when you have encrypted version:
Decrypt the encrypted version; this would obviously require storing the tools necessary to decryption, which is unsafe
Encrypt what you are trying to check, and see if it matches your encrypted version. This does not require the ability to decrypt anything.
I am developing ASP.NET web application for a financial institution that is accessible by authenticated users. As a requirement, password for each user need to be encrypted so that Database Administrators can't have access to any user's password. I have gone through various types of encryption and hashing algorithms, but not sure which can be best suited for my requirement.
Whenever possible, prevent storing passwords all together, for instance by using Windows Authentication. If that is not possible, use the industries best practices in storing passwords. This means that you should:
Use password hashing (not encryption)
Add a salt to the hash
Use a computational intensive hashing algorithm.
The big danger of storing passwords is that the passwords of thousands of users get compromised when someone breaks into your system (or your DBA steals them). Although you can every user's password in your system, users usually use the same password over and over again and this means that the user is at risk when their password is compromised. Of course it is of course bad practice to reuse passwords, this is what users do and it is our job to at least minimize the risk for our users by doing anything that is within our power to do so. Don't forget that failing to do so, might even cause your company to get sued. This happened with LinkedIn.
So for password hashing this practically means that password hashing using MD5 and SHA (even with salting) is pretty useless, since those algorithms are optimized for speed, which allows hackers compute 2300 million salted hashes per second (brute force).
Some well-known computational intensive hashing algorithm are PBKDF2, Bcrypt, PBMAC, and scrypt. In .NET there's an PBKDF2 implementation named Rfc2898DeriveBytes. Here's a good example of the use of Rfc2898DeriveBytes (complete with configurable computational intensiveness, which allows this method to allow to withstand ever increasing computing power of computers).
Using some well-known frameworks that implement best-practices might be a good idea as well. #trailmax already suggested the AspNet Identity framework, which uses PBKDF2. However, prevent from using ASP.NET's SqlMembershipProvider, since it uses SHA by default, and it's actually quite hard to reconfigure it to use a safe method.
I'm encrypting some data that needs to stay on the client, and so will the Salt, Key and IV. Is there a standard way of handling this data on the client to prevent people from discovering it and encryption your data?
I can think of plenty of things to obscure them, but there must be an industry standard way of dealing with this issue.
There's no additional security risk if the IV and salt are known. IV's are safe to store in the clear, and salts are to help prevent precomputation and rainbow tables.
So you're really just talking about the key. There's a couple solutions, each with it's own tradeoffs. In your question, you only mention you need to encrypt data on the client. Does the client not need to decrypt?
If this is a Windows client, you can use the Data Protection API to protect the key under the users credentials.
Protect the key with a passphrase. If you don't mind entering a passphrase each time the client needs the key, this can offer reasonable protection, and it's supported in most cryptosystems like OpenPGP.
If the client only needs to encrypt, you can use a hybrid approach with public keys (like OpenPGP). In this case, you only store the public key on the client, and the private key somewhere safe. When you encrypt data, you'll generate a random symmetric key, and encrypt that under the client's public key. Now if someone compromises the machine, they won't be able to decrypt any of the session keys.
Use specialized hardware like a hardware security module or smart card. This is the most expensive route, but depending on your threat model might be viable.
Asp.net stores the session in a cookie, thus not having to worry about sessions on the server side (traditionally sessions are stored in a database, and lookups are done via a session ID, which is usually a Guid like string).
In my previous question, I was asking about how a spring application stores/creates sessions etc: Spring authentication, does it use encrypted cookies?
Cletus pointed out that storing a username/id in a cookie, although encrypted, is a security issue because the would-be-hacker has both the encrypted text, but also the hacker knows what the actual encrypted text is i.e. the userId or username.
What are you thoughts on this?
I am sure StackOverflow is also using this mechanism, as is **99.9% of asp.net web applications that are using formsauthentication in this manner.
Microsoft's MSDN site itself is filled with examples like:
FormsAuthentication.RedirectFromLoginPage(UsernameTextbox.Text, NotPublicCheckBox.Checked);
In the above code, the username value is stored in the encrypted cookie.
actually, I recall that the asp.net website was hacked because the web.config didn't have the Protection=All in the forms authentication tag.
So is this a real issue?
To repeat what cletus linked to:
In case you're wondering what a "crib" is. see: http://www.faqs.org/faqs/cryptography-faq/part03/
Cryptanalytic methods include what is
known as practical cryptanalysis'':
the enemy doesn't have to just stare
at your ciphertext until he figures
out the plaintext. For instance, he
might assumecribs''---stretches of
probable plaintext. If the crib is
correct then he might be able to
deduce the key and then decipher the
rest of the message. Or he might
exploit ``isologs''---the same
plaintext enciphered in several
cryptosystems or several keys. Thus he
might obtain solutions even when
cryptanalytic theory says he doesn't
have a chance.**
Maybe you should take a look into this document: Improving Web Application Security: Threats and Countermeasures -- Threat Modeling
It's a good start point to understand what security risks are involved and how can you mitigate that threats.