What the hell is my home town's newspaper doing on the front page of hacker news?
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.
"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!"
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)
> 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.
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.
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 ;)
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....
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).
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.
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.
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.
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.
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.
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.
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.
(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 )
Well, the one on the right was on the bottom
And the one in the middle was on the top
And the one on the left got a broken arm
And the guy in the rear, said, "Oh dear"
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... garfieldr@caledonian-record.com
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.
It's silly how this is actually becoming the truth. People use the same password and different usernames for different sites. In the end, remembering your username becomes the problem :)
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.
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.
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?
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.
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?
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.
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.