Your Username Will Now Serve as Your Password and Your Password as Your Username
caledonianrecord.com
caledonianrecord.com
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.
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)
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.
The Caledonian Record does many things that don't really make sense - I'm not completely surprised.
Maybe it's time for a VT HN meetup :)
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
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.
Hey: say hello to Roland for me, will you?
"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!"
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....
It's stupid, but works.
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.
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.
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.
2. Don't allow changing usernames, unlikely to allow changing passwords
3. Indexes? What are indexes?
The usual suspects will be there (within the parameters allowed by the application), but there will be new ones to add to the list.
</sarcasm>
student.setName(resultSet.nextString())); //column 75
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.
(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 )
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.
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.
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.
Oh well, 15 minutes of fame or in this case infame.
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.
"Your password must be unique. Password 'mybirthday' is already in use by 'fred_bloggs'. Please try again."
Username = "wilhil"
Password = "asdfghjkl"
Username = Password
Password = Password
Username & Password = the same?
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).
(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)
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?
> 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.
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?
And yes, you should tune the number of rounds to get something sensible for your application.