101–110 of 110 posts
Earlier quoted context omitted.
Ah, but "1password" is good.
Rule of thumb: If you're going to look for a good implementation of X (anything) then scratch twitter.com from your list before you start.
from the bcrypt page: the other [bit of terrible advice] recommends reversible encryption, which is rarely needed and should only be used as a last resort. Why is reversible encryption a terrible idea for passwords?
In other words, the information needed to extract the true raw-text password is actually included in the encrypted string.
With a hash, only a representation of the raw-text is being stored. Even if you knew exactly what was done to create that representation, you're still a long way off from understanding the raw-text.
If you treat both the key and the salt as being "known to the developer only" and either of these becomes compromised, you still don't have they raw-text of a hash, but you've got everything you need for the encrypted.
Earlier quoted context omitted.
Complete noob. Can you explain this more. if you bcrypt(12345) isn't the result always same ? If the hash varies then what does the inbuilt nonce depend on ?
>> BCrypt::Password.create("hi,mom", :cost => 10) => "$2a$10$L/c.1uoZSh3oaU1fLrnYK.yyU4PiJXsIAzN22qnbU41liyLn5/of 2" >> BCrypt::Password.create("hi,mom", :cost => 10) => "$2a$10$3F0BVk5t8/aoS.3ddaB3l.fxg5qvafQ9NybxcpXLzMeAt.nVWn.NO" >> BCrypt::Password.create("hi,mom", :cost => 10) => "$2a$10$VEVmGHy4F4XQMJ3eOZJAUeb.MedU0W10pTPCuf53eHdKJPiSE8sMK" Despite the pages and pages and pages and pages of conversation about h…
Or did you make a mistake and the cost factors are supposed to different ?
Earlier quoted context omitted.
>> BCrypt::Password.create("hi,mom", :cost => 10) => "$2a$10$L/c.1uoZSh3oaU1fLrnYK.yyU4PiJXsIAzN22qnbU41liyLn5/of 2" >> BCrypt::Password.create("hi,mom", :cost => 10) => "$2a$10$3F0BVk5t8/aoS.3ddaB3l.fxg5qvafQ9NybxcpXLzMeAt.nVWn.NO" >> BCrypt::Password.create("hi,mom", :cost => 10) => "$2a$10$VEVmGHy4F4XQMJ3eOZJAUeb.MedU0W10pTPCuf53eHdKJPiSE8sMK" Despite the pages and pages and pages and pages of conversation about h…
I don't understand it still. The cost factor and the string remains the same but different hashes are produced. So if a user inputs "hi,mom" and the app generates a hash, how is it going to be the same as the one in DB ? Or did you make a mistake and the cost factors are supposed to different ?
Earlier quoted context omitted.
>> BCrypt::Password.create("hi,mom", :cost => 10) => "$2a$10$L/c.1uoZSh3oaU1fLrnYK.yyU4PiJXsIAzN22qnbU41liyLn5/of 2" >> BCrypt::Password.create("hi,mom", :cost => 10) => "$2a$10$3F0BVk5t8/aoS.3ddaB3l.fxg5qvafQ9NybxcpXLzMeAt.nVWn.NO" >> BCrypt::Password.create("hi,mom", :cost => 10) => "$2a$10$VEVmGHy4F4XQMJ3eOZJAUeb.MedU0W10pTPCuf53eHdKJPiSE8sMK" Despite the pages and pages and pages and pages of conversation about h…
I don't understand it still. The cost factor and the string remains the same but different hashes are produced. So if a user inputs "hi,mom" and the app generates a hash, how is it going to be the same as the one in DB ? Or did you make a mistake and the cost factors are supposed to different ?
The documentation for py-bcrypt ( http://www.mindrot.org/projects/py-bcrypt/) doesn't explain what happens, but shows use is very very easy.
EDIT: current guess is that searching for the salt that was used might be part of what makes it hard.
Is there any way to do the above while storing bcrypt passwords on the server? Does using bcrypt in these scenarios force you to use https and pass full text passwords to the server?
I disagree wholeheartedly. The article is based around the fallacy we've seen time and time again, of throwing more cryptography at a problem that cryptography alone cannot solve. In the end, a crappy password is a crappy password. Successfully discouraging your users from using a crappy password has much better repercussions (for the user, for you, and for the web in general) than switching from a hash-based authent…
I'm familiar with cperciva's scrypt, and I think it's a great solution. That said, I've only seen C and Ruby bindings for it. I'd love to recommend its use over bcrypt, as memory constraints are much more expensive than computational constraints, but recommending something most developers don't have access to would result in more weak hashing schemes in production.
[deleted]
They're two completely different things. AES is an encryption algorithm. bcrypt is a special-purpose hash algorithm. If you're confused, I'd highly recommend Practical Cryptography by Niels Furguson and Bruce Schneier: http://www.schneier.com/book-practical.html It will give you much better advice than the internet will.
Why do we care about HTTP Digest? It provides a standard technique to avoid sending clear passwords from client to server. This is particularly handy when the client server communication isn’t encrypted (a poor man’s SSL if you will), but sounds like a good idea in general.
In principle you could create a variant of HTTP Digest using bcrypt instead of MD5 however you’d break browser and rss reader compatibility and AFAIK there are currently no javascript bcrypt implementations.
Hence I’m guessing that web apps storing bcrypt hashed passwords are forced to send clear-ish passwords from client to server and therefore must rely on the presence of an ssl/https connection.
Obviously ssl should be used whenever possible, but I wonder to what extent sending clear passwords doesn’t create other forms of vulnerability?
http://people.redhat.com/drepper/sha-crypt.html Ulrich Drepper's implementation of a work factor in SHA password hashing. He addresses a popular article on bcrypt() and how using SHA allows one to follow NIST guidelines and still have the advantage of a time-consuming algorithm.
me@myhost ~/ :) time perl -le'print crypt("some-password","\$6\$rounds=900000\$myrandomsalt")'
$6$rounds=900000$myrandomsalt$O4u/Z5FRNBi3fw6YhAM1V1hC1LAawq9Ri65Kx77GchzOWieXeRs6w83bYqotyqBcz.WE29NygNli93dBDAbpt/
real 0m3.996s
user 0m3.990s
sys 0m0.005s