Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speed Hashing

codinghorror.com

Post reply on HN
Print view View original

121–130 of 133 posts

Re: Speed Hashing

#121

Post by donpark »

dpark wrote: post #119
donpark wrote: post #118

Earlier quoted context omitted.

Re salt, please see project-rainbowcrack.com as an example of CUDA-driven hash cracking. Re download hash, I think we disagree on what data integrity means. By data integrity, I mean trustworthiness which implies security, meaning file content hasn't been modified in-storage or in-transit. I'm guessing you are using those words to mean protection against transport-errors or typos (credit card entry) for which checksu…

How does pointing to rainbow tables indicate that salt should be secret? That's one of the things that salt prevents, and it does it without being secret . A 32-char random salt could be publicly published for each of your users and it would still do its job. Secrecy doesn't matter. Data integrity is not trustworthiness. Data integrity means I got what you said I should get, not that you are trustworthy (and therefor…

Let's just stop here. Given that we can't even agree on meaning of words, I think continuing this discussion will produce only further disagreements or misunderstandings.

I do, however, appreciate your cordial and elaborate responses for which I thank you.

Re: Speed Hashing

#122

Post by ricardobeat »

minhajuddin wrote: post #5

People should be using stuff like PasswordMakerPro ( https://chrome.google.com/webstore/detail/ocjkdaaapapjpmipmh... ) or something similar to generate big ugly(using the whole character set) passwords. However, secure passwords are still a crutch. We should be fixing the problem of asking for passwords. We already have solutions for this, but they are not widely used. StartSSL( http://www.startssl.com/ ) gives you a…

Until that lovely site goes offline and you, nor anyone else, knows any of your passwords. Not for me.

Re: Speed Hashing

#123

Post by dekz »

ralph wrote: post #85
arethuza wrote: post #45

Earlier quoted context omitted.

Won't that be fairly common? Java's hashCode and the .Net GetHashCode both return 4 byte ints and there are presumably a lot of HashMap and Dictionary objects out there using short strings as keys.

It's very common; the norm even. My point was that "A hash (function) is any function that maps a big variable-length data structure to a smaller (fixed-length) data structure." is incorrect; the source size isn't relevant.

The source size is extremely relevant, in the property that the function is able to work with variable sized input including large input. This definition has obviously embedded its purpose unto itself. The reason we have such cryptographically secure hash functions corresponds to the need to digest large data.

Re: Speed Hashing

#124

Post by yukyukyuk »

Suppose my public facing site is X and I store the hashes on Y. Machine Y is not accessible from X, but X is accessible from Y.

When a user tries to log in, the user ID and supplied password is put in a queue. Y continuously reads this queue (queries X) and tells X whether these log-in attempts succeed or not.

The hashes stay on Y, along with hash(salt, password). If X is compromised, Y will be fine since there is no route from X to Y. So the most any attacker can gain is a list of logins.

Of course this will not protect from an inside job, but that's a whole other story.

Any problems with this approach?

Re: Speed Hashing

#125

Post by yukyukyuk »

tptacek wrote: post #79
eruquen wrote: post #49

Nobody mentioned pepper yet. Not the "static salt" variant which you might find while googling. That is just more security by obscurity. I'm talking about adding a random string of fixed length characters to the (salted) password that is not saved anywhere. At login, it requires a bit of brute-forcing on the server to check the hash since we have to go trough all possible pepper strings. This adds a few ms (e.g. with…

That's because it's a silly idea which is inferior to cryptographic adaptive hashing, as is done by bcrypt, scrypt, and PBKDF2. If you want to provide a work factor, use a real one.

To anyone who sees the above comment: this is a classic troll comment. The user 'tptacek' can't think of any flaws in this idea, but because it isn't his own, and because his inability to find any flaws causes him frustration, he feels the need to denigrate the idea by calling it "silly". It isn't particularly clear A) why the so-called "pepper" method would be inferior to some others and B) why it couldn't be combined with tptacek's suggestions.

Even in tptacek's follow-up comment further down, there is still not even a single reason given as to why one of these ideas is inferior to another. If you are comparing ideas X and Y, and you think X is inferior to Y, you cannot demonstrate that fact to others by saying "Y is a great idea" because X may be an equally great idea, even if you think it is "silly" and you "condescend" to it.

This is the difference between good writing and bad writing.

A bad writer will tell you how to fell ("John and Cindy sat outside, watched the amazing sunset, and felt happy to be together")

A good writer will make you feel something. Here is a cheesy example, this might work if you dig 90210, dubious in these parts, I admit. Or it just might induce nausea... ("John looked out at the sunset. Rays of light spilled through the clouds and over the rust-colored hills. A bird chirped twice in the distance by the lone birch tree before fluttering off. He could just barely make out a mark on on the tree. He turned to Cindy and asked 'Can you see it, where I carved our initials?' She looked out toward the tree and smiled. She looked over and cooed "Aww...", and then she snuggle-leaned into him.")

Good writing is a lot of work, but the alternative is to look like a jerk /Fezzik

Re: Speed Hashing

#126

Post by pjscott »

mckoss wrote: post #93

In reality the usable space is substantially less; you can start seeing significant collisions once you've filled half the space. More problematic, the chance of any collisions is 50% when you have filled just sqrt(space) - known as the birthday paradox.

It looks like he just misread this article, which is kind of a disaster itself -- it recommends storing MD5 hashes of passwords, maybe with a salt if you want to be extra secure.

http://www.skrenta.com/2007/08/md5_tutorial.html

Edit: Oh dear, there's a followup post:

http://www.skrenta.com/2007/08/crypto_vs_the_working_coder.h...

Re: Speed Hashing

#127

Post by minhajuddin »

ricardobeat wrote: post #122
minhajuddin wrote: post #5

People should be using stuff like PasswordMakerPro ( https://chrome.google.com/webstore/detail/ocjkdaaapapjpmipmh... ) or something similar to generate big ugly(using the whole character set) passwords. However, secure passwords are still a crutch. We should be fixing the problem of asking for passwords. We already have solutions for this, but they are not widely used. StartSSL( http://www.startssl.com/ ) gives you a…

Until that lovely site goes offline and you, nor anyone else, knows any of your passwords. Not for me.

With passwordmaker pro, the passwords are not really 'stored' anywyere. It just computes a hash using the 'domain name' a Master Password and some other predefined stuff. So, it's not dependent on any site. So, it uses a different password for each domain (because the domain is an input to the hash). This way, even if a site you are using is compromised, and the passwords leaked, the effect is local to that site.

Re: Speed Hashing

#128

Post by Dylan16807 »

jsharpe wrote: post #65
mistercow wrote: post #34

>A given hash uniquely represents a file, or any arbitrary collection of data. At least in theory. It really bothers me when people misuse "in theory" like that. "In theory" means "we have a model that makes good predictions in some circumstances, but there are cases where it may fall short". But a model in which hashes uniquely represent arbitrary collections of data is a model which allows for infinite compressibil…

It bothers me too when people reverse "in theory" and "in practice", which are really quite different things! Clearly in this case he actually meant "in practice".

I disagree. The theory is not that collisions don't exist. The (probabilistic) theory is that you will never find one. In practice hash functions tend to have flaws that are discovered over time, ruining this theory.

Re: Speed Hashing

#129

Post by lysium »

rmc wrote: post #58
lysium wrote: post #22

While long and random passwords are a good thing, there are still applications that make that very difficult to use. I'm looking at you, Apple AppStore, letting me choose a new password after only the second wrongly-entered, disallowing copy&paste on that website to enter the new password, requiring JavaScript on that website to enforce the no-copy&paste rule and then not showing me the characters I enter. That's rid…

If you are using long passwords, you don't need to use purely random text, you can use a phrase.

Unfortunately, my password manager is bad at generating phrases and I'm bad at generating random phrases.

Re: Speed Hashing

#130

Post by lysium »

tzs wrote: post #115
lysium wrote: post #22

While long and random passwords are a good thing, there are still applications that make that very difficult to use. I'm looking at you, Apple AppStore, letting me choose a new password after only the second wrongly-entered, disallowing copy&paste on that website to enter the new password, requiring JavaScript on that website to enforce the no-copy&paste rule and then not showing me the characters I enter. That's rid…

That is indeed annoying. As a work around, if you use a browser or browser extension that lets you modify the DOM on the fly, you can disable the paste blocking. For instance, in Safari, use "Inspect Element" on the password field, find the onpaste="..." attribute, double click the onpaste and change it to something that isn't a valid event name. You can then paste in the password field. It should be reasonably possi…

That's good to know, I'll try it next time!
Post reply on HN