Your Username Will Now Serve as Your Password and Your Password as Your Username(caledonianrecord.com)
caledonianrecord.com
Your Username Will Now Serve as Your Password and Your Password as Your Username
http://caledonianrecord.com/FormLayout.asp?formcall=30&dest=/main.asp%3FSearch%3D1%26ArticleID%3D51476%26SectionID%3D1%26SubSectionID%3D145%26S%3D1
93 comments
The Caledorian Record "IT" office 48 hours ago:
"Wait Walter, what? I don't understand this email."
"Turns out our $8/hr rent-a-coder destroyed the user table. All that is left are the passwords, which for some reason are in a different table in plain-text."
"Crap. Wait, what are you holding?"
"Its the hard drive from the server. I'm going to send it to one of those recovery places. The guy on the phone said that they could do a recovery for 10k."
"What?! I'm not paying that much. Wait, doesn't the server need that drive?"
"Dunno. It seems to still be working. Lots of lights flashed when I took it out, but I ignored it."
"Fine, then what do we do. We can't tell people to log in with their passwords, can we?"
"Why not? Its not like we'll be mocked by some roving gang of geeks. The passwords are still associated with their member IDs. We can just put in some bullshit about security and switching the username and password. We'll ignore what they type in as username!"
loudly and in unison
"Winning!"
"Wait Walter, what? I don't understand this email."
"Turns out our $8/hr rent-a-coder destroyed the user table. All that is left are the passwords, which for some reason are in a different table in plain-text."
"Crap. Wait, what are you holding?"
"Its the hard drive from the server. I'm going to send it to one of those recovery places. The guy on the phone said that they could do a recovery for 10k."
"What?! I'm not paying that much. Wait, doesn't the server need that drive?"
"Dunno. It seems to still be working. Lots of lights flashed when I took it out, but I ignored it."
"Fine, then what do we do. We can't tell people to log in with their passwords, can we?"
"Why not? Its not like we'll be mocked by some roving gang of geeks. The passwords are still associated with their member IDs. We can just put in some bullshit about security and switching the username and password. We'll ignore what they type in as username!"
loudly and in unison
"Winning!"
I wondered the same thing. I actually built the original Caledonian-Record site back in high school when the Caledonian was partnered with Helicon (anyone remember hcr.net? Oh the nineties). I was very relieved to see that the link wasn't some old embarrassment of mine from 1996.
Oh I remember Helicon... I can't remember what I was using at the time either Kingdom connection or I was still using the Socialism Online bulletin board. I bet the website looked spectacular back then in all it's glory ;)
nek4life, where are you from St. Jay? I'm from Littleton myself and was pretty dumbfounded when I found the Caledonian Record as the #2 result on the front page of HN.
I actually just signed my grandmother up to their service here and all it is, is a paid subscription to pdf copies of their newspaper as they release it. Theres not exactly much to protect there and worst case scenario is that someone gets some free copies of the paper. I don't think its such a big deal for them to be a little lax with password security given what you get behind the security wall. (as long as people aren't using that same password everywhere ... which may be the real problem here)
I actually just signed my grandmother up to their service here and all it is, is a paid subscription to pdf copies of their newspaper as they release it. Theres not exactly much to protect there and worst case scenario is that someone gets some free copies of the paper. I don't think its such a big deal for them to be a little lax with password security given what you get behind the security wall. (as long as people aren't using that same password everywhere ... which may be the real problem here)
> as long as people aren't using that same password everywhere
Most people do reuse passwords. That's the reason this is significant. It wouldn't be newsworthy if a service like this screwed up and made getting free copies of the hometown newspaper easy.
Most people do reuse passwords. That's the reason this is significant. It wouldn't be newsworthy if a service like this screwed up and made getting free copies of the hometown newspaper easy.
Yeah I'm from St. Johnsbury but now I'm currently living in Burlington, VT. I was in total shock seeing the caledonianrecord.com domain on the front page. They used to have the actual articles online so I'm surprised to hear that they switched over to publishing the pdf's instead but that probably makes sense as the staff doesn't have to web publishing skills (as easy as that seems to the people that are reading this.) The switching of the username and password baffles me but perhaps they gave out generated usernames and passwords to begin with so it wasn't such a big deal. Although I'm really questioning the logic right now.
St. Johnsbury natives on Hacker News? Say it isn't so! Another one here.
The Caledonian Record does many things that don't really make sense - I'm not completely surprised.
The Caledonian Record does many things that don't really make sense - I'm not completely surprised.
I'm from Johnson originally but now living in Essex Jct.
Maybe it's time for a VT HN meetup :)
Maybe it's time for a VT HN meetup :)
Yeah, definitely! Had no idea there were so many of us!
P.S. Any Ruby folks in Southern VT (or S/W NH or N/W MA)? We'd love to hear from you! :) http://greenriver.org/people/jobs
P.S. Any Ruby folks in Southern VT (or S/W NH or N/W MA)? We'd love to hear from you! :) http://greenriver.org/people/jobs
There are quite a few of us out here in Western Mass - check out http://wmassdevs.com
Yeah that would be fun for sure. I've updated my HN profile and alluded to my email address within.
I'd be up for it.
(I hide out in Jeffersonville)
Small world!
I lived in Bethlehem and Franconia for many years, before moving to Vermont for a while (still along 302, though-- but I've been in Norway for the past 13 years or so. Never expected to see the Caledonian Record on HN.
I lived in Bethlehem and Franconia for many years, before moving to Vermont for a while (still along 302, though-- but I've been in Norway for the past 13 years or so. Never expected to see the Caledonian Record on HN.
I'm surprised about the number of Vermonters on here, but I guess a post like this would bring them out. I'm in Rutland myself, but have business in St. Johnsbury / Lyndonville.
Whoa... Internet in the NEK now? The largest introduction of new technology I ever saw growing up in Walden was getting a paved road that wasn't the highway. I figured up there you guys were still busy wrapping copper wires to make your memory cores ;)
Woah hello from Bethlehem NH
"Whoa" is right. I used to live next to the Arlington Kosher Hotel...
Hey: say hello to Roland for me, will you?
Hey: say hello to Roland for me, will you?
Just passed through there for the first time a few weeks ago. Beautiful town you got there!
Another STJ guy here absolutely shocked to see the Caledonian Record on hacker news. Beat LI!
Strange, my account name is now 'password' and it seems there are many duplicates! Shoot!
My password is 12345 and I cannot figure out why my login is failing now, even with this change.
Edit: you know, now that I think about it they could be using Javascript to generate an MD5 hash of the username, which is now the password, and submit that to the login form. But....
Edit: you know, now that I think about it they could be using Javascript to generate an MD5 hash of the username, which is now the password, and submit that to the login form. But....
The library I work for actually does this. Their last name is their password and their barcode is their username -- yet we display forms the other way around to make their account look more secure (cuz a last name is obviously not a secure password).
It's stupid, but works.
It's stupid, but works.
How do you change your password?
By getting married and adopting your (new) husband's/wife's lastname, apparently.
"Honey, will you change my library password?" (Pulls out ring.)
I want to change my password. Now!
People cannot change their password. Whatever the system has for your last name is your password. This is common in libraries because a) your barcode is assumed to be mildy private and b) online access to your account doesn't give you access to physical objects (even if you request something, we require barcodes and picture ID to circulate the item) thus mitigating any financial losses to the user.
This does raise concern regarding unauthorized access to licensed content. If you google for EZProxy logins you can find dozens of lists of accounts to Universities. My experience is that libraries rely on publishers to ulinately report abuse though at which point we suspend the barcode and issue a new one to the legitimate user.
This does raise concern regarding unauthorized access to licensed content. If you google for EZProxy logins you can find dozens of lists of accounts to Universities. My experience is that libraries rely on publishers to ulinately report abuse though at which point we suspend the barcode and issue a new one to the legitimate user.
Not unsurprisingly, x' AND email IS NULL; -- works as the username with no password. Injection FTL.
Good find, though I don't think most of it is necessary.
It seems like any username that includes a semicolon at any point will authenticate. I can't imagine what their code would have to look like in order for that to happen.
It seems like any username that includes a semicolon at any point will authenticate. I can't imagine what their code would have to look like in order for that to happen.
Especially considering they're actually paying monthly for it.
http://news.ycombinator.com/item?id=2330694
http://news.ycombinator.com/item?id=2330694
So much for the security change. I thought that kind of injection was really a thing of the past. Injection is the web segfault.
Passwords as usernames, human sacrifice, dogs living with cats. Mass hysteria!
Seriously though, I can't understand what their rationale for this would be. Not to mention, as other commenters have pointed out, how they will handle all the users whose former passwords were common phrases like password, secret, ilovebieber, etc. will now be duplicates.
Seriously though, I can't understand what their rationale for this would be. Not to mention, as other commenters have pointed out, how they will handle all the users whose former passwords were common phrases like password, secret, ilovebieber, etc. will now be duplicates.
1. "SELECT * FROM Users WHERE Username=\"" + $username + "\" AND Password=\"" + $password + "\""
2. Don't allow changing usernames, unlikely to allow changing passwords
3. Indexes? What are indexes?
2. Don't allow changing usernames, unlikely to allow changing passwords
3. Indexes? What are indexes?
And they said that print news was dying due to the industry's inability to innovate... Pfft!
Discounting the absurdity angles of all of this, there is always one positive: We'll all have an opportunity to update our list of disallowed passwords.
The usual suspects will be there (within the parameters allowed by the application), but there will be new ones to add to the list.
The usual suspects will be there (within the parameters allowed by the application), but there will be new ones to add to the list.
And the saddest thing is they're actually paying monthly for that CMS. See the source code and then http://www.going1up.com/main.asp?SectionID=6&SubSectionI...
Putting aside the issues we all know exist with this, I wonder what their rationale was...
Security is hard.
If you're asking for an account name and password form someone, you're effectively committing to playing security hardball. Also, you're asking the users to trust you, and perhaps the level of trust that you're askign for is more than you really need.
Stackoverflow is an interesting case where they thought about issues of identity and authentication, and decided to go with OpenId. Their rationale would be something along the lines of "we want to map comments to an identity, but we don't need/care about authentication, we can let someone else do that".
Unfortunately, OpenId kind of sucks, but that's a different story.
An interesting example is HackerNews where they keep a cookie around so I don't need to log in everytime. This is enormously much less secure (anyone else on the same machine can impersonate me just by going to the HN website). But the security implications of someone impersonating me are low (shoot, given my contrarian nature and history of Iconiclasm and Heresy someone else trying to 'destroy' my online rep would probably actually improve it instead :D )
Now Facebook does the same thing, but in Facebook's case this is enormously bad, evil and wrong (tm) since the data they control access to is much more sensitive and private.
Speaking of different stories, here's another one to illustrate when you want to be able to uniquely identify someone, but going with a full on username/password system is overkill and more hassle than it is worth.
Was talking to some guys who want to take registrations/expressions of interest for an upcoming Science Fiction convention. The convention is a couple of years out, so presumably some proportion of the people will need to change their address details between now and then. But if they do a name/password thing, people will forget the passwords (and choose badly even if they do remember it), it imposes a security and trust burden upon them to maintain the database securely.
Basically, they need to identify the people to a reasonable degree of security, but names/passwords is overkill.
So I decided that what they needed was a shared secret instead. If the person gives their email address when they sign up (and sign ups range from OMG take my money now to "eh, send me a reminder when we get to three months out"), then when that person wants to change their name/address details, they just send them an email with a link. The link contains the shared secret built in (e.g. a token). The shared secret will eventually expire, but for a while they can get in and edit their own details. If someone doesn't want to give their email when they sign up, no problem, they just can't offer them those convenience features.
If you're asking for an account name and password form someone, you're effectively committing to playing security hardball. Also, you're asking the users to trust you, and perhaps the level of trust that you're askign for is more than you really need.
Stackoverflow is an interesting case where they thought about issues of identity and authentication, and decided to go with OpenId. Their rationale would be something along the lines of "we want to map comments to an identity, but we don't need/care about authentication, we can let someone else do that".
Unfortunately, OpenId kind of sucks, but that's a different story.
An interesting example is HackerNews where they keep a cookie around so I don't need to log in everytime. This is enormously much less secure (anyone else on the same machine can impersonate me just by going to the HN website). But the security implications of someone impersonating me are low (shoot, given my contrarian nature and history of Iconiclasm and Heresy someone else trying to 'destroy' my online rep would probably actually improve it instead :D )
Now Facebook does the same thing, but in Facebook's case this is enormously bad, evil and wrong (tm) since the data they control access to is much more sensitive and private.
Speaking of different stories, here's another one to illustrate when you want to be able to uniquely identify someone, but going with a full on username/password system is overkill and more hassle than it is worth.
Was talking to some guys who want to take registrations/expressions of interest for an upcoming Science Fiction convention. The convention is a couple of years out, so presumably some proportion of the people will need to change their address details between now and then. But if they do a name/password thing, people will forget the passwords (and choose badly even if they do remember it), it imposes a security and trust burden upon them to maintain the database securely.
Basically, they need to identify the people to a reasonable degree of security, but names/passwords is overkill.
So I decided that what they needed was a shared secret instead. If the person gives their email address when they sign up (and sign ups range from OMG take my money now to "eh, send me a reminder when we get to three months out"), then when that person wants to change their name/address details, they just send them an email with a link. The link contains the shared secret built in (e.g. a token). The shared secret will eventually expire, but for a while they can get in and edit their own details. If someone doesn't want to give their email when they sign up, no problem, they just can't offer them those convenience features.
Now Facebook does the same thing, but in Facebook's case this is enormously bad, evil and wrong
Selfishly, I disagree. I hate sites that constantly forget who I am. I would be totally happy for every site, including my bank, to set a perpetual cookie. If I want them to forget me I can explicitly log out.
Maybe for people who don't know better you have a point, I don't know. But for me, Facebook remembering me isn't bad, evil, and wrong, it's good, righteous, and correct.
Selfishly, I disagree. I hate sites that constantly forget who I am. I would be totally happy for every site, including my bank, to set a perpetual cookie. If I want them to forget me I can explicitly log out.
Maybe for people who don't know better you have a point, I don't know. But for me, Facebook remembering me isn't bad, evil, and wrong, it's good, righteous, and correct.
I see your point, and I agree that for a well defined environment (e.g. my PC, at home, that no one else touches on pain of very painful things).
However, the big picture is that in general insecure should not be the default option.
Take your example, all you have to do is use it once on another persons computer, and then forget to explicitly log out ... and BAM you're compromised. Of coruse, this would be unlikely, since you are smart and can remember, but for other people they don't have the habit of logging out because they don't need to, so it would be very very easy for them to forget to do this.
(Ideally) The security of the user's data should not rely on eternal vigilance on the part of the user.
Better would be an opt in cookie ssytem, that you can explicitly say "keep me logged in on my home computer". That way when you or our hypothetical less than eternally vigilant user logs in to a public machine they can simply forget to click that option and it doesn't hurt their security.
However, the big picture is that in general insecure should not be the default option.
Take your example, all you have to do is use it once on another persons computer, and then forget to explicitly log out ... and BAM you're compromised. Of coruse, this would be unlikely, since you are smart and can remember, but for other people they don't have the habit of logging out because they don't need to, so it would be very very easy for them to forget to do this.
(Ideally) The security of the user's data should not rely on eternal vigilance on the part of the user.
Better would be an opt in cookie ssytem, that you can explicitly say "keep me logged in on my home computer". That way when you or our hypothetical less than eternally vigilant user logs in to a public machine they can simply forget to click that option and it doesn't hurt their security.
I'm pretty happy with a "keep me logged in forever" checkbox. The thing I hate is "keep me logged in for a week" checkboxes. It's a pointless middle ground.
Iconoclasm and Heresy? Is that an Advanced Civilization reference?
Correct! You sir, get an upvote :D
(And to pre-empt the inevitable karma snipe, it was in the normal game as well. Civil Disorder (level 7) + Iconoclasm and Heresy (level 8) was an evil, evil combo :D )
(And to pre-empt the inevitable karma snipe, it was in the normal game as well. Civil Disorder (level 7) + Iconoclasm and Heresy (level 8) was an evil, evil combo :D )
Probably some variant of "Whoops. We named the username column 'password' and the password column 'username'. Guess we need to fix this!"
I've seen far too many codebases that use the order of the returned fields rather than the field names. Scary.
But it's faster that way, and you don't have to store the name in every row like with those No-Seequill whatnots.
</sarcasm>
</sarcasm>
Your closing sarcasm tag isn't warranted, in a large number of circles.
Aye, me as well. And later written my fair share of them when the going got rough.
their rationale was ir
This might actually be a security improvement, with people choosing names with numbers and capitals in them, and ridiculously stupid passwords.
But do they have a "recover username" form that requests your already known password?
Is it April 1st already?
... also your username is now 0fa9d314017d68a235015a9344bc9c09bbe87ec3
Wonderful, do you know how accounts I have to change because of this reckless post?
Ah, that little Bobby Tables. What a prankster he is.
I assume someone has already emailed this guy?
Reed Garfield, Information Technology [Snip] Joined the Caledonian in 1963
Reed is among the longest tenured employees of the paper. Though technically retired from his long held position of Production Manager, Reed still makes vast contributions to the daily operation of the Caledonian through his mastery of technology systems.
He has three grown children and lives in Lyndonville with his wife.
Related Links: • Email Reed... [email protected]
Reed Garfield, Information Technology [Snip] Joined the Caledonian in 1963
Reed is among the longest tenured employees of the paper. Though technically retired from his long held position of Production Manager, Reed still makes vast contributions to the daily operation of the Caledonian through his mastery of technology systems.
He has three grown children and lives in Lyndonville with his wife.
Related Links: • Email Reed... [email protected]
No need to berate the guy. We've all made silly mistakes before. Yes, I know that this is bad, but there's no need to send him harassing emails.
Sorry, I wasn't advocating berating the guy.
There is a need to send him one email, saying "Hey, noticed you made a mistake. It's pretty public (see hackernews), and you should fix it soon. Hope that helps!"
I hoped that someone would reply, saying, "Yup, I emailed him." and thus mitigate the potential flood of email. Since there was no announcement on the website to the tune of "Whoops, we made a security blunder, you'll have to do X to log in now", I assumed the guy was oblivious.
There is a need to send him one email, saying "Hey, noticed you made a mistake. It's pretty public (see hackernews), and you should fix it soon. Hope that helps!"
I hoped that someone would reply, saying, "Yup, I emailed him." and thus mitigate the potential flood of email. Since there was no announcement on the website to the tune of "Whoops, we made a security blunder, you'll have to do X to log in now", I assumed the guy was oblivious.
SEO trick? Get people all over the Internet talking about this insane "Security Change" and increase hits. (Would love to see analytics on this). Would be surprised if it will last.
Oh well, 15 minutes of fame or in this case infame.
Oh well, 15 minutes of fame or in this case infame.
This is my hometown newspaper - I saw this the other day when looking for an article... is there any good reason for this? I cannot fathom what's going on.
For what it's worth, the opinion of the paper myself and those I know have had is that it's rather poor quality, but there's not enough market for competition.
For what it's worth, the opinion of the paper myself and those I know have had is that it's rather poor quality, but there's not enough market for competition.
You see negligent security practice. I see clever marketing ploy.
Oh, so it's like a credit card!
My hometown paper, growing up. Seriously, though...
Holy potatoes, I'm truly and deeply dazzled.
That's a lot of "azerty" accounts...
Good point...unless they require unique passwords (huh?) or disambiguate username clashes via password (double huh?), seems like this wouldn't work very well at all.
Or the password is the subscriber number and the username was their email. Happens often that the online access for a periodical is your subscriber number found on the address label.
Nice...
"Your password must be unique. Password 'mybirthday' is already in use by 'fred_bloggs'. Please try again."
"Your password must be unique. Password 'mybirthday' is already in use by 'fred_bloggs'. Please try again."
Do we then need even a username?
so...
Username = "wilhil"
Password = "asdfghjkl"
Username = Password
Password = Password
Username & Password = the same?
Username = "wilhil"
Password = "asdfghjkl"
Username = Password
Password = Password
Username & Password = the same?
WTF?!
I can't help wondering how this happened.
They should make the "order" irrelevant. ie silently retest using password/username reversed.
What are the chances that both (password,username) and (username,password) succeed? Very low I guess.
If it ever happens, reset password and send a mail about that (on both accounts).
What are the chances that both (password,username) and (username,password) succeed? Very low I guess.
If it ever happens, reset password and send a mail about that (on both accounts).
http://codahale.com/how-to-safely-store-a-password/
(PS: most of the comments on this item aren't very useful. Try to be useful when commenting, even in the face of stupidity such as this)
(PS: most of the comments on this item aren't very useful. Try to be useful when commenting, even in the face of stupidity such as this)
On this submission? Come on. You obviously grasp that some submissions are lighter-hearted than others, otherwise you wouldn't have left http://news.ycombinator.com/item?id=2307252 on the mspaint.exe expressed as PCM item.
Since you edited out "be useful or go elsewhere," I know that you're thinking your orders to us are a bit across the line, too. They are. Might as well finish it off and edit them all the way out.
Now, on to your URL:
I've tired of people mindlessly chirping the bcrypt approach for storing passwords, particularly that very blog post, when really there is absolutely nothing wrong with hashing. This line particularly irks me, amongst others:
> Salt or no, if you’re using a general-purpose hash function designed for speed you’re well and truly effed.
The author glosses right over keeping a separate salt (shared secret) outside of the database itself, so that you need two separate compromises -- application code and database -- in order to retrieve plaintext passwords. He also claims that "salts won't help you" plain text full stop, without justifying that remark well in the article, and completely avoiding their utility at preventing a rainbow attack.
Instead, the entire article resorts to fear mongering, and I'm tired of people citing it. I will continue using hashing, and watch as the Anonymous groups and so on pick off the low-hanging fruit.
If you mindlessly copy and paste that URL to me without fully and objectively understanding the implications of what you're implementing, and why bcrypt might not be right for you, you really should step back and rethink your decision. In particular, if your app is handling a lot of logins, you're going to become CPU bound extremely quickly. Using the author's benchmark of 0.3 seconds for a simple password hash, how many simultaneous login attempts do you think it's going to take to saturate a core?
Since you edited out "be useful or go elsewhere," I know that you're thinking your orders to us are a bit across the line, too. They are. Might as well finish it off and edit them all the way out.
Now, on to your URL:
I've tired of people mindlessly chirping the bcrypt approach for storing passwords, particularly that very blog post, when really there is absolutely nothing wrong with hashing. This line particularly irks me, amongst others:
> Salt or no, if you’re using a general-purpose hash function designed for speed you’re well and truly effed.
The author glosses right over keeping a separate salt (shared secret) outside of the database itself, so that you need two separate compromises -- application code and database -- in order to retrieve plaintext passwords. He also claims that "salts won't help you" plain text full stop, without justifying that remark well in the article, and completely avoiding their utility at preventing a rainbow attack.
Instead, the entire article resorts to fear mongering, and I'm tired of people citing it. I will continue using hashing, and watch as the Anonymous groups and so on pick off the low-hanging fruit.
If you mindlessly copy and paste that URL to me without fully and objectively understanding the implications of what you're implementing, and why bcrypt might not be right for you, you really should step back and rethink your decision. In particular, if your app is handling a lot of logins, you're going to become CPU bound extremely quickly. Using the author's benchmark of 0.3 seconds for a simple password hash, how many simultaneous login attempts do you think it's going to take to saturate a core?
I agree you that this article has nothing to do with salting, and I don't know why the grandparent comment was even made, but there are a few points I would like to make about what you've said.
> when really there is absolutely nothing wrong with hashing.
Hashing is millions of times better than storing the plaintext. Adding a salt probably increases the workload by about as much as going from salted hash to bcrypt [constant time lookup in rainbow table -> exponential time in length of password -> higher constant factor exponential time]. But I must disagree with you saying there's nothing wrong with hashing, however. There is something wrong with hashing, and that is that it's possible to brute force many passwords. However you're perfectly right that going hash+salt to bcrypt doesn't do nearly as much as going from plaintext to hash+salt.
And you're also right in that the simple passwords will fall anyways. You could have it take 30 seconds per password and an attacker could still get the passwords a couple percent of your users (who picked '123456', 'password', etc). If I pick '$yN3,A%2vq{-', no matter if the server is using MD5-crypt or even scrypt, you won't be getting my password.
> you're going to become CPU bound extremely quickly
This is one of the only valid criticisms of bcrypt, and it is a significant one. One of the nice things about it, though, is you don't have to use the 0.3 second time. That's just chosen arbitrarily. If you think that's too high, then go with 0.03 seconds, or 0.003 seconds. Surely you can deal with that requirement. Granted, brute forcing is now 1000 times faster -- but hey, it's 1000 times slower than bruteforcing a hash.
Anyhow, I don't disagree with most of what you're saying. I just wanted to point out that it's still possible to go with bcrypt by just decreasing the workload to a reasonable level for your application; I'm not trying to say you're wrong.
> when really there is absolutely nothing wrong with hashing.
Hashing is millions of times better than storing the plaintext. Adding a salt probably increases the workload by about as much as going from salted hash to bcrypt [constant time lookup in rainbow table -> exponential time in length of password -> higher constant factor exponential time]. But I must disagree with you saying there's nothing wrong with hashing, however. There is something wrong with hashing, and that is that it's possible to brute force many passwords. However you're perfectly right that going hash+salt to bcrypt doesn't do nearly as much as going from plaintext to hash+salt.
And you're also right in that the simple passwords will fall anyways. You could have it take 30 seconds per password and an attacker could still get the passwords a couple percent of your users (who picked '123456', 'password', etc). If I pick '$yN3,A%2vq{-', no matter if the server is using MD5-crypt or even scrypt, you won't be getting my password.
> you're going to become CPU bound extremely quickly
This is one of the only valid criticisms of bcrypt, and it is a significant one. One of the nice things about it, though, is you don't have to use the 0.3 second time. That's just chosen arbitrarily. If you think that's too high, then go with 0.03 seconds, or 0.003 seconds. Surely you can deal with that requirement. Granted, brute forcing is now 1000 times faster -- but hey, it's 1000 times slower than bruteforcing a hash.
Anyhow, I don't disagree with most of what you're saying. I just wanted to point out that it's still possible to go with bcrypt by just decreasing the workload to a reasonable level for your application; I'm not trying to say you're wrong.
Bcrypt is a hash. Hash is a general term.
Okay, yes. By 'hash', I meant generic, general purpose hashing function. MD5. SHA-1. SHA-2. SHA-3 (any of the finalists). Anything that is fast enough that you would use it to compute a cryptographically secure checksum of a large block of data.
Your comment and descendants are the only ones of value on this submission, along with one other comment from Stormbringer. Mine was a desperate attempt to provide some kind of substance before the comments descended into the jokes and one-liners that now fill the page. (I'm surprised hunter2 hasn't been mentioned yet).
The MSPaint submission was clearly a bit of fun. Password security isn't.
I felt in this case that the comments that were being made sent the wrong message about what HN strives for, but I know it's dangerous to criticise comments or submissions on HN, that's supremely frowned upon, so I apologise for sullying the thread with such criticism.
edit: I mean, read the comment thread from top to bottom - isn't that exactly the kind of elitist snorting that the "My fellow geeks, we need a talk" submission was trying to address?
The MSPaint submission was clearly a bit of fun. Password security isn't.
I felt in this case that the comments that were being made sent the wrong message about what HN strives for, but I know it's dangerous to criticise comments or submissions on HN, that's supremely frowned upon, so I apologise for sullying the thread with such criticism.
edit: I mean, read the comment thread from top to bottom - isn't that exactly the kind of elitist snorting that the "My fellow geeks, we need a talk" submission was trying to address?
This is an old comment, so I'll not type out a long reply, but note that bcrypt has random salts while your scheme has a fixed salt. With a large database of passwords plus your fixed salt, an attacker can try each calculated hash against each hashed password in your database. With sufficiently long random salts (bcrypt has 2^176 ~= 10^53 bits of salt, if I count correctly), the attacker only gets to try a calculated hash against one hashed password.
And yes, you should tune the number of rounds to get something sensible for your application.
And yes, you should tune the number of rounds to get something sensible for your application.
I'd be lying if I didn't believe that they would do something this stupid. They recently put the site behind a pay wall and I can no longer catch up on hometown news as a result. Who ever running that business is an idiot.