I am using the PKCS#5 standard to generate a key using a random and unique salt and the user`s password in input. Consider this key as the "encryption" key.
The "encryption" key is used to encrypt a random AES key. Each users have an AES key associated to their profile.
So, a user`s profile will contains this informations:
--> password hash for authentication purpose.
--> salt used in the PKCS#5 algo. (From the PKCS#5 V2.0 documentation, we know that this information needs no protection).
--> the encrypted AES key generated randomly and encrypted with the "encryption" key generated by the PKCS#5 algo with the salt and the user`s password
I was asking myself if it is dangerous to be in possession of the password`s hash, the salt and the encrypted AES key IN THE SAME TIME. I am 99.9% sure that this is not a problem, but can it facilitates the work of an attacker being in possession of all those details?
The password hash also needs to use a salt, otherwise dictionary attacks are possible and two users who happen to pick the same password will have the same hashed password stored in the DB.
I would suggest this: Just use PKCS#5 twice; once to generate the hashed password (which you store in the clear), and once to generate the encryption key (which you do not).
Make sure the salts are large, random, and independent, and then there will be no detectable relationship between the password hash and the encryption key. That is what the salt is for, after all.
[update, to elaborate a bit]
Pick two salts s1 and s2. Make sure each is at least 64 bits, random, and independent.
Use the password + s1 as input to a PKCS#5 HMAC on the empty string. This is the "hashed password".
Use the password + s2 as input to a PKCS#5 encryption scheme to encrypt the actual data.
Store the hashed password, s1, and s2 in the clear in the database. Done.
Related
Can anyone explain how to encrypt id using eloquent.Present i am using thirdparty library to encrypt and decrypt id.I want know how to encrypt and decrypt ids using eloquent orm in slim.
Encrypting ids is a terrible idea. It doesn't provide any security and is bad for performance.
Encryption is only meant for sensitive data (e.g. credit card numbers). Ids are just unique identifiers and don't contain any sensitive information (or least shouldn't). If you need an identifier for a private URL, generate a random token and store it in a separate column.
Encrypting an integer with Laravel gives you a string with ~190 characters. You shouldn't use that as a primary/foreign key.
Since Laravel's encrypter uses CBC Mode, encrypting the same value gives you a different result each time. So you can't use Model::find($id) to retrieve an entry from the database. You would have to fetch and decrypt all ids to find the right one.
i want to know performance wise which is better to provide message authenticity, ECDSA signatures or hash based signatures, although i have read the comparisons of ECDSA with RSA, but not found with hash based signatures. Can ECDSA signatures replaced with Hash based signatures improves the message authenticity or not.
ECDSA is a hash based signature, in that the data gets hashed, then ECDSA is performed on the hash (not the whole data)
When it comes to data verification there are three main approaches:
Straight hash (e.g. SHA-2-256)
The fastest option to verify
If you are only protecting against line corruption this is a valid choice.
Otherwise, requires that the hash/digest value be sent over a secure (from tamper) channel, because the tampered can easily transmit the digest along with the tampered document
Provides no proof of origin
HMAC (e.g. HMACSHA256)
Requires that both the sender and receiver share the secret key
Either the sender or receiver having the key stolen puts both sides at risk
Secret key needs to come from key agreement algorithms (ECDH) or be transmitted in secret (encrypted)
Proves the document came from someone with the shared secret.
Digital Signature (e.g. ECDSA, RSA signature)
The sender is the only entity with the private key, receiver needs public key (non-secret)
Public key can be embedded in an X.509 certificate to provide a notarized association of public key to the signer
Or the public key can be transmitted raw over a secure (from tamper) channel.
Provides strong assurances about the document origin, since they shouldn't share their private key.
All three options use a hash algorithm to reduce the original data, the rest of the algorithms are what do you do with that data. There's not really a standard definition of "secure", you have to say "secure against (something)". ECDSA provides more assurances than HMAC as long as the private key isn't shared. But if HMAC provides enough assurance it is probably faster on average (specialty hardware aside).
I would like to know what type of hash used for active directory passwords and if there is a way to change the type of hash
A user's password hash can be stored in Active Directory using two different proprietory hash algorithms: LM hash and NT hash.
The less secure LM hash is disabled by default by group policy on later Server OS versions but can be reenabled again.
Aside from that the only other way you can affect this is to enable storing passwords with reversible encryption using group policy.
After that is enabled, when you change your password a password filter called RASSFM.DLL is used to store the password using reversible encryption. The key that is used to do this is G$MSRADIUSCHAPKEY, which is stored as a global LSA secret. This key is decrypted using a static key (hardcoded in the DLL). The result of this operation is combined with a 16-byte random value (generated every time someone changes their password) and that key is used to encrypt a Unicode version of the password using the RC4 algorithm.
This information is then saved in the userParameters attribute.
In case of claim based authentication which uses SSO, an application receives a token from the issuer for a particular user and that token contains the claims as well as some sort of digital signature in order to be traced by the application that an issuer is a trusted one.
I want to know, if there are some sort of algorithms involved by which this application recognizes an issuer?
I had read that issuer has a public key and all the other applications have their own private key, is it true?
There are many protocols, formats and methods of doing Single Sign On such as Security Assertion Markup Language (SAML), OpenID and OAuth. The goal is for one entity, such as a website, to identity and authenticate the user (such as through a user name and password) and other entities, such as other websties, trust the evidence of that authentication through a token. This means users need not remember yet another password and each website maintain their own list of passwords.
This trust is usually enforced through cryptography using a digital signature. Digital signatures are used because it allows the trusting entity to verify token was (1) issued by the authenticating entity only and (2) not tampered with without being able to impersonate (pretend to be) the authenticating entity.
As you say above, this is performed using asymmetric or public key cryptography. Symmetric cryptography, such as the AES or DES algorithms, use a single key to encrypt and decrypt data. Asymmetric cryptography, such as the RSA algorithm, uses two related keys. Data encrypted using one can only be decrypted by the other and vice versa.
One key is usually kept secret, called the private key, and the other is distributed widely, called the public key. In the example above, the authenticating entity has the private key that allows it to encrypt data that anyone with the public key can decrypt.
It would seem to follow that the authenticating entity would just encrypt the user details and use that as the token. However, commonly used asymmetric algorithms like RSA are very slow and encrypting even small amounts of data can take too long.
Therefore, instead of encrypting the user details, the authenticating entity generates a "hash" or "digest" and encrypts that. A hash algorithm converts a piece of data into a small number (the hash) in a very difficult to reverse way. Difference pieces of data also create different hashes. Common hash algorithms include Message Digest 5 (MD5) and Secure Hash Algorithm (SHA) and its derivatives like SHA1, SHA256 and SHA512.
The hash encrypted with the authenticating entity's private key is called a digital signature. When it receives the token, the trusting entity decrypts the token using the authenticating entity's public key and compares it to a hash it calculates itself. If the hashes are the same, the trusting entity knows it has not been modified (because the hashes match) and it must have come from the authenticating entity (because only it knows its private key).
If you want more information about SAML and claims-based authentication, I found this video very helpful. It does get complicated rather quickly and you may need to watch it multiple times but Vittorio covers most of these concepts in great detail.
I have MD5 hashes of passwords in a database that I want to use against HTTP AUTH DIGEST. But in reading the docs, it looks like the digest hash contains a hash of the username,realm and plaintext password. Is there any way to use the MD5 hash of the password in this situation?
No. If the hash they need is generated like so:
MD5(username + realm + password)
You are out of luck.
If they are hashing the password like so:
MD5(MD5(password) + username + realm)
You'd be able to do that with just the hashed password. But it doesn't sound like that's what's going on.
No, you have to store in the tables the HA1 hash of Digest and use that for other types of auth (forms and Basic). See here: Storing password in tables and Digest authentication
No, this is not possible. The whole point of digest authentication is to avoid replay attacks, i.e. were somebody has only a hashed version (of some authentication data) rather than the real data.
Not only is it a hash of username, real, and plaintext password, but also a nonce, which will change every time. So you really need the plaintext password.
No. In digest authentication, the password is hashed with a challenge, there is no way to make it work with another hash.
Basic auth over HTTPS is more secure and it should work with your hashed password.