Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm looking at the various bcrypt implementations across several languages and noticing the character limitation across most - specifically, the 72 character maximum that node-bcrypt, php's bcrypt, and py-bcrypt all exhibit.
What are the advantages and disadvantages if an application were to run user input through, say, a SHA-256 or SHA-512 checksum beforehand to enable longer inputs for bcrypt?
The CLI application found here is limited to 8-56 "characters" inclusive (it's C, so a character can be anything I suppose). Heaven knows why you would create limits for something that you feed into a password based key derivation function afterwards (which almost certainly will take unlimited input).
An additional secure hash with sufficient strength and output size will not do anything to degrade security.
Encode the result to hexadecimals before feeding it to a bcrypt library, which is almost certainly expecting a String (don't get struck by the "odd" 00h byte). You might as well use SHA-256, I don't think a few bits more or less will make a difference if you feed it into bcrypt afterwards. Otherwise you may be forced to use base64.
Finally, try not to get into this situation, performing non-standard cryptography is almost certainly a bad thing.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have a plain text and its cypher text. I know that the algorithm used was MD5. I want to break all cypher texts that are produced using the same algorithm.
Is there any way to do so?
Kerckhoffs's Principle applies here. Knowing the mathematics, and the interaction between the plaintext and ciphertext, will not let you break the MD5 hashing algorithm.
This is due to Shannon's principles of cryptography, outlined in 1945, "Confusion and Diffusion". In simple terms, this means that any even reasonably good encryption algorithm does not show a clear relationship between the cleartext and the ciphertext.
The short answer to your question is no, there is no way to break MD5 purely by knowing a cleartext and a ciphertext. There's no key, so you can't reverse engineer it like a simple XOR cipher.
However, **as MD5 is a very quick, processor-light algorithm, it has been (and is still) possible to simply bruteforce a vast array of cleartext strings, then compare your target ciphertext to the resulting **rainbow table.
This site can help you do this: MD5 Decryptor
I will mention, however, that it's generally rare that there is a use for this outside of computer misuse, which I will strongly caution you against.
I hope this was helpful.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
There is a password generator that generates passwords based on known rules (a minimum of 10 characters in length, at least 1 of each of uppercase, lowercase, and numeric characters).
No ability to see the source code for this generator. I am just able to generate passwords and automate this process.
How would you test if this generator provides unique passwords assuming each password meets rules specified?
Thanks,
Racoon.
It does not generate unique passwords - that much I can guarantee you.
If you run this password generator a hundred billion times, what are you expecting to be true of the output? Are you really expecting that every one of those hundred-billion passwords will be different?
If what you're instead trying to ask is whether the passwords will be reasonably unique, then you need to define what you mean by 'reasonably unique'.
It also depends on the nature of the rules you specify for generating these passwords. If you specify a maximum length for passwords, then you have by definition set an upper limit on how many unique passwords there even are. Even if you don't, the only way you're getting guaranteed-unique passwords is if said passwords are allowed to grow to lengths that will make them totally impractical to use.
I think my question was incorrect. Every password generator sooner or later provides a value that have been earlier. Better think of randomness than unuqueness.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about programming within the scope defined in the help center.
Improve this question
i guess that algorithms used to crypt password becomes weaker year after year due to the new technologies (CPU more powerful, GPU...),
So; does this mean that a user registred in 2006 is less protected than who has registred in a 2012?
Then; how to update the password of that user of 2006? (for example Yahoo, if am registred since 2006, then my password takes less time to crack than the password i'll put in 2012, so how Yahoo will do to update my password to the new powerful system?)
In other words: how to migrate from a system to another (from MD5 to Bcrypt for example for the existing MD5-hashed passwords)
There are two actual problems:
CPU power increases, so brute force cracking increases
Older algorithms get less secure
The latter one is fixed by changing the way you normally hash and store passwords in your database. You can already do this every time a user logs in when their password is stored in the old format.
The first one requires an actual change of the password and you should 'force' users to update their password every so often and check (or at least indicate) password strength when they enter a new one.
Another way to counter the increased CPU power is to limit the number of password tries after a number of failed ones and thus prevent brute forcing of the password.
In general though I think proper management of password storage is lacking in most websites and systems.
If your hashing scheme involves just repeatedly hashing the current value (1000s of times), then you can always later increase the iteration count (just not decrease it).
You can use bcrypt as your iteration function so you get the benefits of both schemes.
Like this:
var hash = bcrypt(pw, salt);
for N iterations:
hash = bcrypt(hash, salt)
You can always "append" new iterations in the future.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
This question does not appear to be about programming within the scope defined in the help center.
Improve this question
I'm playing around with text transformations - ciphers. From all that I have surveyed it seems that all of these algorithms either break even in terms of transformed message length, or get larger. Are there any known algorithms/text transformations that when applied to a message actually make the message smaller (not counting the key, of course)?
For instance, RSA, when you encode the message, makes the encrypted message quite a bit larger than the original. Is there any such thing as that only the message becomes smaller, instead of larger, after (encryption, transformation, etc whatever you want to call it)?
I'm not doing this as part of security, so whether or not it's hackable is not of any interest to me.
P.S. I've done a lot of research in this area already through search engines (google, wikipedia, etc) but I have found no results. I don't want to say that such a technique doesn't exist without at least posting the question publicly first.
Thanks!
Compression tries to make input smaller. Obviously lossless compression will not make every input smaller, since that's impossible.
You can encrypt the compressed input if you want that. In principle compression and encryption are orthogonal concepts, but in some situations the length of the compressed text can be used to attack the system.
At first I thought about language transformation. Some English phrases translate to a single Chinese symbol. That's not a rigorous, mathematical example, but I suppose it qualifies.
Alternatively, from a bit-wise perspective, it wouldn't be possible to cipher/encode 2 bits of information in 1 bit.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Could anyone explain to me the vulnerability of Mifare Classic with AES-128 bit key diversification? Do Mifare Classic chips protect against cloning?
First of all, Mifare Classic does not use AES encription algorithm. NXP decided to use Crypto-1 instead. Unfortunately they made a serious mistake with implementation of the internal Random Number Generator so that it is possible to predict first 12 bits of total 48 bits of session key. The rest can be cracked by brute force and air traffic analyses within a reasonable period of time.
NXP strongly advises to not use Mifare Classic in new projects. Instead, it is recomended to use UltralightC or DesFire EV1. Those cards can communicate using AES encription (DES, 3DES, 3KDES are also avaliable). Until now, DesFire EV1 has not been cracked. Previous versions of DesFire were broken in research labs by power consumption analyses. EV1 is protected against this method of attack.
Regarding the cloning - it is not possible to copy the contents of a card and paste it directly to another one, as each card have different UID that cannot be altered, so it will not be an exact copy. If the attacked system is checking UID, then the cloned card will not work. But it is possible to build device which will simulate a Mifare card (in this case it is possible to set any UID).