In LPC, it use crypt() to encrypt the password.
How can I decrypt it?
MudOS (now Fluff OS! https://www.fluffos.info/ ) uses a one-way hashing algorithm, but it's not a very strong one (or was historically). A lot of the mudlibs (the libraries that contain the LPC and the calls to hashing the passwords) furthermore had security issues where the salts were not random (or random enough), so they may be easier to break than normal.
Some MUDs even used the password itself as salt so for some hashed passwords you had the first part of the password actually be the first letters of the real password. Take a good close look at how they were salted and you may have an easier time decrypting them.
Otherwise, I suggest looking at the tool suggested by Rob.
If this is based on Unix's crypt, despite it's name suggesting "encrypt" it's actually a one-way hash function and it intentionally has no reverse (decryption). If the password is reasonably simple, then John the Ripper is a nice password cracker, but it can take a very long time if the password is not trivial.
Related
Basically what the title says. If I have a password, of say "APPLEPIE" is it safe to use "APPLEPIE" as the key when I RC4 it? Is it possible to break the RC4 encryption when you know the Key and Plaintext or are short and the same?
This should be handled with a key generation algorithm like PBKDF2, which will allow you to securely generate a hash from your password in a way that is appropriate for password verification (which is what I assume you're doing).
While it is possible to generate a system by which RC4 would be safe this way (by converting the password into an RC4 key using a good KDF (such as PBKDF2), and then generating a random nonce), this is a lot of overhead to no purpose. You'll wind up with a much longer final cipher text for the same level of security, and it'll take you longer to generate it. In the end, you'll have just created an extremely complicated secure hash function (whose first step is "do the only thing you needed to do anyway). And you'll probably have made a mistake along the way, making the system insecure. RC4 can be tricky to do correctly and has known related-key attacks; hence the break of WEP.
My program includes a feature where users could encrypt certain data using a password. As not all passwords will be a proper length, are there any insecurities in fixing this by hashing the password (with a good algorithm) to generate a fixed-length key which will then be fed into AES?
EDIT: Never mind, see http://en.wikipedia.org/wiki/Key_derivation_function
If password is easy to break because it is short - hashing it will not help as all what will be needed is to apply the same hash function during brute force attack. And it may not be possible to make hash function completely secret as it must be exposed at some point to hash the password.
I'm learning to do proper crytographic implementations, and I thought as an exercise I would create an encrypted text editor.
My first attempt used a SHA-512 hash of a user-provided password as the key, and it functioned just fine. Though I was storing the IV in the header of the file, unprotected and that had me worried.
Then I read on stackoverflow that I should be using SecretKeyFactory (I'm using Java) to do PBE, and now I additionally need to provide a salt. So now I'm storing the salt in the header as well, but that would seem to ruin the whole purpose of having a salt. So how is this supposed to work? When I have Alice pick a password for her file when she saves, am I supposed to say "Here, memorize this random number along with your password."? I would like for the resulting file to be able to be e-mailed to Bob, so the salt can't be stored locally.
As my app stands, the IV and salt are out in the open. I would like for my user to only have to know the password when they send their file to Bob while remaining cryptographically secure, but I can't find any examples of how this is done.
Thanks for any help!
It is safe to store an IV along with the data, that is how IVs are used. Your method is ok, pick a block cipher, use cipher block chaining and an IV, and you're away.
There are many ways to create a key and iv from a passphrase, but one of the more common ones involves HMAC with SHA-1, in an algorithm that takes some salt and other things into account, to build a sufficiently bit-mixed key and iv.
The technical standard is the PKCS#5 v2.0 PBKDF2 algorithm, to which OpenSSL implements a C interface to a method that can do this, but as far as I know, no command line method.
I have heard that the only purpose of a salt is to prevent rainbow table attacks, but surely it must have more value than this? Would it not prevent a dictionary-based attack too? And what about brute-forcing, would a salt be of any use there? And could you explain why, please?
Second, suppose I had an algorithm that took the microtime, a 128 character salt and a random number between 1 billion and 10 billion, and hashed them together. Would this provide a great level of security? For even if the attacker knew one of those details, it seems to me that it would still be computationally infeasible to calculate the rest. Is that right, though?
Thanks,
Ben
Edit: To clarify, the attacker doesn't have access to the hashing algorithm, so they can't spam any information to the system. All they have is the hash and they have to work out how it was compiled. Surely even if they knew how the hash was generated, trying to brute-force all the combinations with a long salt would make it unrealistic to do?
Also, the hash isn't of the user's password or username, it's just a random set of characters used for authentication. So the salt and random number don't need to be stored, just the resulting hash. In that case would the above system, represented in something like the below code, be a good system to prevent an attacker from being able to realistically guess what a user's hash might be?
$salt = "some random characters I made up";
hash('sha256', microtime(true).$salt.mt_rand(1000,9999));
I know that's only 1000-9999 instead of the billions mentioned above.
Thanks again.
No - It only prevents rainbow table attacks. As a attacker needs to build the rainbow table for each password entry. Because the salt adds a lil spice which differentiates the password hash from all the others.
Dictionary-based and Brute-forcing attacks are essentially the same thing here. Salting doesn’t stop these as your validation algorithm is something like
plain-text-passwd = 'secret provided by user'
salt = getSalt(username) //looks the salt value up in database based on the users username
hash-password-in-db = getPassword(username) // looks up hashed password bassed on users username
if(hash(plain-text-passwd + salt) == hash-password-in-db) //if true, password is correct
With Dictionary-based and Brute-forcing attacks the value for plain-text-passwd is spammed by the user which in turn gets hashed with the salt. So salting does nothing
Second, suppose I had an algorithm...
This is pointless, you need to store all this information against the user information table, where a 5 character salt value serves the same purpose.
A rainbow table is an optimisation method that can be used for both dictionary attacks and brute-force attacks.
A correctly-used salt makes precomputation infeasible for dictionary and brute-force attacks. Since a rainbow table is a kind of precomputation optimisation, so it is one of the optimisations that is neutered by salting.
Your second example is really just a longer salt, with some lower-entropy portions. It is worrying that you differentiate "a random number" and "a salt", since a salt should be a random nonce.
There are many articles and quotes on the web saying that a 'salt' must be kept secret. Even the Wikipedia entry on Salt:
For best security, the salt value is
kept secret, separate from the
password database. This provides an
advantage when a database is stolen,
but the salt is not. To determine a
password from a stolen hash, an
attacker cannot simply try common
passwords (such as English language
words or names). Rather, they must
calculate the hashes of random
characters (at least for the portion
of the input they know is the salt),
which is much slower.
Since I happen to know for a fact that encryption Salt (or Initialization Vectors) are OK to be stored on clear text along with the encrypted text, I want to ask why is this misconception perpetuated ?
My opinion is that the origin of the problem is a common confusion between the encryption salt (the block cipher's initialization vector) and the hashing 'salt'. In storing hashed passwords is a common practice to add a nonce, or a 'salt', and is (marginally) true that this 'salt' is better kept secret. Which in turn makes it not a salt at all, but a key, similar to the much clearly named secret in HMAC. If you look at the article Storing Passwords - done right! which is linked from the Wikipedia 'Salt' entry you'll see that is talking about this kind of 'salt', the password hash. I happen to disagree with most of these schemes because I believe that a password storage scheme should also allow for HTTP Digest authentication, in which case the only possible storage is the HA1 digest of the username:realm:password, see Storing password in tables and Digest authentication.
If you have an opinion on this issue, please post here as a response.
Do you think that the salt for block cipher encryption should be hidden? Explain why and how.
Do you agree that the blanket statement 'salts should be hidden' originates from salted hashing and does not apply to encryption?
Sould we include stream ciphers in discussion (RC4)?
If you are talking about IV in block cipher, it definitely should be in clear. Most people make their cipher weaker by using secret IV.
IV should be random, different for each encryption. It's very difficult to manage a random IV so some people simply use a fixed IV, defeating the purpose of IV.
I used to work with a database with password encrypted using secret fixed IV. The same password is always encrypted to the same ciphertext. This is very prone to rainbow table attack.
Do you think that the salt for block
cipher encryption should be hidden?
Explain why and how
No it shouldn't. The strength of a block cipher relies on the key. IMO you should not increase the strength of your encryption by adding extra secrets. If the cipher and key are not strong enough then you need to change the cipher or key length, not start keeping other bits of data secret. Security is hard enough so keep it simple.
Like LFSR Consulting says:
There are people that are much smarter
than you and I that have spent more
time thinking about this topic than
you or I ever will.
Which is a loaded answer to say the least. There are folks who, marginally in the honest category, will overlook some restraints when money is available. There are a plethora of people who have no skin at the fire and will lower the boundaries for that type,....
then, not too far away, there is a type of risk that comes from social factors - which is almost impossible to program away. For that person, setting up a device solely to "break the locks" can be an exercise of pure pleasure for no gain or measurable reason. That said, you asked that those who have an opinion please respond so here goes:
Do you think that the salt for block
cipher encryption should be hidden?
Explain why and how.
Think of it this way, it adds to the computational strength needed. It's just one more thing to hide if it has to be hidden. By and of it's self, being forced to hide ( salt, iv, or anything ) places the entity doing the security in the position of being forced to do something. Anytime the opposition can tell you what to do, they can manipulate you. If it leaks, that should have been caught by cross-controls that would have detected the leak and replacement salts available. There is no perfect cipher, save otp, and even that can be compromised somehow as greatest risk comes from within.
In my opinion, the only solution is to be selective about whom you do any security for - the issue of protecting salts leads to issues that are relevant to the threat model. Obviously, keys have to be protected. If you have to protect the salt, you probably need to review your burger flippin resume and question the overall security approach of those for whom you are working.
There is no answer, actually.
Do you agree that the blanket statement 'salts should be hidden' originates from salted hashing and does not apply to encryption?
Who said this, where, and what basis was given.
Should we include stream ciphers in discussion (RC4)?
A cipher is a cipher - what difference would it make?
Each encrypted block is the next block IV. So by definition, the IV cannot be secret. Each block is an IV.
The first block is not very different. An attacker who knows the length of the plain text could have a hint that the first block is the IV.
BLOCK1 could be IV or Encrypted with well known IV
BLOCK2 is encrypted with BLOCK#1 as an IV
...
BLOCK N is encrypted with BLOCK#N-1 as an IV
Still, whenever possible, I generate a random (non-null) IV and give it to each party out-of-band. But the security gain is probably not that important.
The purpose of a per record salt is to make the task of reversing the hashes much harder. So if a password database is exposed the effort required to break the passwords is increased. So assuming that the attacker knows exactly how you perform the hash, rather than constructing a single rainbow table for the entire database they need to do this for every entry in the database.
The per record salt is usually some combination of fields in the record that vary greatly between records. Transaction time, Account Number, transaction Number are all good examples of fields that can be used in a per record salt. A record salt should come from other fields in the record. So yes it is not secret, but you should avoid publicising the method of calculation.
There is a separate issue with a database wide salt. This is a sort of key, and protects against the attacker using existing rainbow tables to crack the passwords. The database wide salt should be stored separately so that if the database is compromised then it is unlikely that the attacker will get this value as well.
A database wide salt should be treated as though it was a key and access to the salt value should be moderately protected. One way of doing this is to split the salt into components that are managed in different domains. One component in the code, one in a configuration file, one in the database. Only the running code should be able to read all of these and combine them together using a bit wide XOR.
The last area is where many fail. There must be a way to change these salt values and or algorithm. If a security incident occurs we may want to be able to change the salt values easily. The database should have a salt version field and the code will use the version to identify which salts to use and in what combination. The encryption or hash creation always uses the latest salt algorithm, but the decode verify function always uses the algorithm specified in the record. This way a low priority thread can read through the database decrypting and re-encrypting the entries.