New answers tagged passwords
5
You are correct: generally it is required to synchronize or otherwise synchronize information if you want to use a password based key derivation function (PBKDF) for sending messages.
That doesn't mean that using a password on the client side a derived key on the server side doesn't have advantages:
the password isn't stored on the server side, so an ...
1
Sending symmetric key is equivalent to sending password (used for PBKDF) - they are both secret information that require secret channel. Sending session symmetric key encrypted with asymmetric cryptosystem doesn't require secret channel - you use public key of recipient (for instance taking it from certificate signed by root certificate that you trust, say ...
1
Trying to use a PBKDF for transferring data over a network is not appropriate. The place to use a PBKDF is when you're protecting data at rest, e.g. some sort of archive file like a zip file or a backup. In works well in those contexts.
3
KDFs are better used for offline protocols. What is often used for your second case are Key-agreement protocols. As far I know, there's no secure way of using KDFs in such interactive context where both parties need to know the key a priori. Key-agreement protocols make it feasible to compute a shared-secret (the encryption/decryption key) on demand - both ...
1
PBKDF is intended to derive a key (specific length, hard to guess) from a password. That's it.
Indeed, when exchanging messages encrypted only with a symetric cipher, at the end all involved parties need to have the same key. The key needs to be shared somehow at some point.
If what I understood is correct, then I don't see the goal of using a PBKDF ...
1
Length has very little to do with it
It depends on the brute force strategy used by the attacker, and more importantly how quickly they can arrive at your password.
The most basic - and to some degree old fashioned way - was to use a dictionary. The algorithm would be as simple as looping through every word in the dictionary, creating a hash, and then ...
0
Padding is a common occurrence and a part of poor security. People typically put some numbers at the end of their favorite password and a ! or - or whatever symbol if symbols are required.
e.g.
xyz1A! the padding is whatever the person needs to add to meet the minimum length and complexity requirements. 1 for a number A for upper case ! for a symbol might ...
0
It's a little bit safer, but not much.
Let's assume an attacker has a list of all possible passwords, sorted by probability in descending order. Assuming the attacker has no information about you, they will try all the passwords in the list from the most probable one, so 1234, love, dog, cat etc. If your password is #n on the list, then brute force will ...
19
There's a 2013 article in Ars Technica that refutes the notion that long passwords are necessarily hard to crack. It details how security researchers Kevin Young and Josh Dustin turned to text from Wikipedia and Project Gutenberg as a seed to come up with longer and longer phrases to try in their password crackers, and managed to crack some impressively ...
4
The attacker wouldn't need to know the padding pattern, consider the following
The padding is done client side
Attacker scripts and posts directly to the server
The attacker reverse engineers the client front end and adds that padding to the script they are writing to post requests to the server, the complexity generated by appending the padding has been ...
27
If we take two password strings of different length and attempt to bruteforce match them, it is obvious that the longer one will take longer to crack on average.
Actually, that might be obvious to you, but it's not true.
A brute force search is one where an attacker has a long list of passwords, and tries them in succession. Now, if the attacker is at all ...
3
Generally you don't want to switch algorithms in cryptography. You'd have to deal with different workloads. Furthermore, the choice of algorithm would be just another salt, if a tiny one. However, your approach doesn't disallow the building of 5 separate rainbow tables. So the reason for a salt isn't met.
It is unclear why you would not be able to use a ...
3
Modern FileVault is a relatively slow hash. hashcat supports attacking FileVault 2 hashes as mode 16700.
As an example of real-world attack capability, if a seven-character password were truly randomly generated, then it would take a little more than seven years to fully exhaust on a rig with six reasonably fast GPUs:
$ hashcat -a 3 -m 16700 -w 4 filevault....
2
Take advantage of the fact that you can store information on the client. If you're okay with requiring network access to perform authentication, then you can use a simple protocol to enforce incorrect-pin limits.
Store a random 128-bit key, $s$, on the client. On registration, client sends the server $\operatorname{Hash}(s, pin)$. Then sends 9999 hashes $\...
4
PIN check is bound to rely on trusted device or security by obscurity.
If a 4-digit Personal Identification Number is stored and validated in an device (possibly composite, like combination of server and mobile device) of known construction, and an adversary acquires/extracts all the data stored in the device, including the (possibly encrypted or hashed) ...
2
That is impossible (at least as I understand your question) because:
The ability to privately test whether two strings are equal (even if just 2 bits, even with security only against semi-honest parties) implies oblivious transfer. (Kilian: A general completeness theorem for two party games)
It's impossible to realize oblivious transfer from hash functions ...
Top 50 recent answers are included
