Hot answers tagged authentication
13
This is an active area of research. There have been attempts at creating usable security tools and lots of user studies of existing tools (typically with critical results).
A good anthology for work in this area (a few years old now) is Security and Usability edited by Lorrie Cranor and Simson Garfinkel.
There is also a workshop every year called Symposium ...
11
A few observations:
RC4 suffers from related key attacks. This means your idea of concatenating a 224 bit key and a 32 bit IV is not a good idea. You should rather use $\operatorname{SHA-256}(Key||IV)$
Remember that a (Key, IV) pair must not be reused, ever.
A 32 bit IV can work if it's a counter, but IMO such a scheme is unnecessarily fragile. I'd rather ...
9
Cryptography is being a lot of places already and people might just know about it. For example, whenever you access an HTTPS page, that's cryptography protecting you.
For desktop applications, many people use the Truecrypt application to protect their files. You also see a similar application in Windows BitLocker.
As for why more people aren't using ...
9
There's an obvious solution using DH: Alice has a private key $a$ and a public key $g^a$; Bob has a private key $b$ and a public key $g^b$.
When Bob sends a message, he computes the shared secret value $(g^a)^b$, converts that into a MAC key (possibly using a nonce to prevent key reuse), computes the MAC of the message, and sends the message and the MAC ...
8
The main weakness in cryptography is that people are involved.
I'm also wondering why the allegedly secure websites (financial/healthcare) that I use, still use password access and still have "security questions" in case I forget my password, where the security questions aren't very secure.
There are more secure schemes, however they cost money. ...
8
No, you are not leaking any information except how to MAC those specific values with the specific key you are using. Using a short message is exactly as secure as using a long message.
For the following, remember the definition HMAC (K,m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)). There are two hashes here, an outer hash and an inner hash nested inside the ...
7
If your password database will never be compromised, you can store plaintext passwords and nobody will be bothered. The only thing about plaintext passwords is that they can be accidentally remembered by admins who see them - a simple base64 will fix that. Equivalently, MD5 or SHA1, with salt or without, is just as fine.
If your password database is ...
7
You could encrypt them using some key derived from the user's password (to your site).
Of course, this assumes that you get your user's passwords in plain text (or in any form which is always the same) - thus you need to have an encrypted connection to your user. Do not allow any non-SSL login.
You can use some key derivation function like PBKDF or bcrypt ...
7
No, RC4 is not completely broken. It is possible to use it properly. It's just not very likely that an average developer will do so.
RC4 is not a good choice for new systems. It is tricky to use properly. There are some serious pitfalls which, if you're not an expert cryptographer, can bite you in the butt. In fact, if you take a quick look in the ...
6
If this is simply the AES permutation on a single block, it's hard to find such a pair.
If it's AES-ECB with multiple blocks, you can pick each block from either (x1,y1) or (x2,y2), producing a new message that contains parts from each of them.
With other modes it depends on that mode, but with many modes there will be a similar mixing attack as for ECB.
5
"Authentic" is defined with regards to an identity. A message from Bob is authentic only insofar as Bob is distinct from Charlie. There must be something which, from the outside, makes Bob and Charlie two different entities.
In a computerized world with networks, Alice can "see" other people only through the data they send. Moreover, everybody can buy a ...
5
For Diffie-Hellman, adequate security is achieved provided that:
we work modulo a prime $p$ big enough to resist discrete logarithm (1536 bits are sufficient);
the order of the subgroup generated by $g$ is a multiple of a big-enough prime integer $q$ ($q$ should have length $2n$ bits to achieve $2^n$ security);
the private exponents are randomly chosen in ...
5
The distinction between real and fake salt is arbitrary. I suppose that your method would be called "fake salt" by those who make the distinction (concatenation versus "separate input parameter to the algorithm), but there is not really a difference in practice, as long as the hash algorithm is secure.
A bit more secure (in the sence of "provenly secure") ...
5
If the CA issued something with a CSR as the dominant part of the To-Be-Signed field, it wouldn't be a X.509 certificate and hardly any existing software would know what to do with it. I guess the original CSR could be added as an extension, though.
Therefore, I suppose you are really asking why the X.509 certificate format wasn't originally specified to ...
5
What you're suggesting is likely good enough, and very likely far more secure than just about any other lock on your house.
If the only hash function you can find is MD5, go with it, but make sure to HMAC with the passphrase as the key. Again, it's not going to be the weak point of your security. I'm sure I could pick the lock on your front door faster than ...
5
What you describe looks secure to me, but excessively complicated. The following simpler procedure should suffice:
When a password reset token is requested:
Generate a secure random token and save it (or a cryptographic hash of it) in the database, along with a timestamp. Overwrite the previous token, if any.
Send the token to the user by e-mail ...
5
The idea that cryptography alone can provide non-repudiation is a myth. I realize it is one that is taught in many crypto textbooks -- but the textbooks are wrong.
See, e.g., my answer here and here.
I could suggest some constructions (e.g., sign the message, append the signature to the message, then encrypt it using an authenticated encryption mode of ...
5
To get non-repudiation, you must have a "proof" which can be used against the signer himself. Symmetric cryptography, by itself, will not help you there, because a cryptographic proof can only come from some "secret" which is under exclusive control of the signer, and the symmetric model assumes that there is a shared secret between two entities. The concept ...
4
This question comes up often enough in the context of cryptography that it probably is relevant in a practical sense. I suspect we'll hear even more about it if homomorphic encryption raises interest in "computation in an adversarial setting".
It's not just theoretically unsolvable. A great many software development organizations have tried to keep data ...
4
Well, one obvious way to do this would be using RSA with a large 'public' exponent. That is, it is the traditional RSA sign/verify operation except that, instead of the usual optimization of having a small 'e' value, you would have a large one (a bit smaller than the modulus); and then derive d from e, p and q in the usual manner.
As for the requirement ...
4
Short version: SPKI links not only names, but authorizations to keys. Also, it uses a better syntax (S-expressions) than X.509 certificates.
Long version:
What problem does it solve?
Both the traditional CA-based public-key infrastructure (PKI) and PGP's web of trust (and other similar systems) do mainly one thing: Linking names to public keys.
The ...
4
The client nonce is there to protect the client against a replay attack. Without the client nonce, an attacker could intercept the initial request for a nonce by CS, and respond with an old nonce that the server used previously. Then, the client would use that old nonce and make an API call with it, which the attacker would again intercept, and the attacker ...
4
It is very similar to how we authenticate ourselves to a website. During registration, the website must store enough information to, at some time in the future, convince itself that the person trying to authenticate now is the same person who registered at some time in the past. For online services, this typically involves storing some function of the ...
4
That's a reasonable solution if you can't use a random salt. If you personalize your hash function for your application, then the salt is globally unique for each user. (e.g. use sitename||username as salt) The only salt reuse happening is that older passwords of the same user have the same salt. But that's a very minor issue.
I disagree with Polynomial who ...
4
It's fine, as others have noted.
However, by invoking PBKDF2 twice (first to check the password, then to derive the actual key), you're essentially doubling a legitimate user's workload, whereas an attacker still only needs to run it once for each guessed password. Thus, you're cutting the legitimate user's advantage in half, or, equivalently, wasting one ...
4
You didn't mention at what level you're hoping for, so I'll provide a few resources, and you can figure out which ones best meet your needs.
UMAC: Fast and secure message authentication. John Black, Shai Halevi, Hugo Krawczyk, Ted Krovetz and Phillip Rogaway, CRYPTO 1999. (This research paper describes UMAC, a fast Carter-Wegman style hash. It also gives ...
4
The short answer is: They prepend bits in that way because the scheme is not secure without them. While they might not explain it in English, their proof makes it clear where they use it.
Let us construct an attack against the scheme that does not prepend a bit to the blocks. The same idea will work against a version of the scheme that prepends the same ...
4
CRAM-MD5 is a protocol to demonstrate knowledge of a password. In the context of email, it is sometime used by an email client to authenticate to a POP, IMAP, or/and SMTP server. Basically, the password is used as the key of HMAC-MD5 in a challenge-response protocol.
Among positive things there are to say about CRAM-MD5:
The password is not exchanged in ...
4
Here's a better solution, using a Merkle tree.
Suppose the string $S$ is $n$ letters long. Build a binary tree with $n$ leaves, with each leaf corresponding to one letter in the string. Then, each node corresponds to a substring: the $i$th leaf corresponds to the $i$th letter in the string, and an internal node $x$ corresponds to the substring obtained by ...
3
First, convert the string which is to be encrypted into a sequence of bytes. UTF-8 is easy enough; you may reduce the size a bit, depending on what you know on the input strings (e.g. if the strings are domain names, they are ASCII-compatible, so you need only 7 bits per character -- actually a bit less). For the rest of this post, we need to assume that the ...
Only top voted, non community-wiki answers of a minimum length are eligible
