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

Passwords in plain text

plaintextoffenders.com

Post reply on HN
Print view View original

81–90 of 116 posts

Re: Passwords in plain text

#81

Post by aianus »

HarrietJones wrote: post #80

A lot of talk of passwording concentrates on threats at the technology end, and they ignore threats at the user end. Emailed Passwords are a failure from a tech point of view, but they allow users to create more complex passwords without punishing them when they forget that password. As it is, I have situations now when the complexity requirements of a password combined with the fact that I need to sign in to a separ…

1Password has mobile apps so you can copy and paste passwords on mobile (pretty rare, since most services will remember you). Once you start using it you get really used to it and you won't go back. You just have to force yourself those first few days.

Re: Passwords in plain text

#82

Post by aianus »

jivid wrote: post #77
jackalope wrote: post #74

Earlier quoted context omitted.

How is downloading a key pair generated by someone else safer? If this is only for login purposes (I don't use AWS, so maybe there is another reason), you should generate your own key pair and send them only your public key (which doesn't require an encrypted transfer, BTW). If AWS knows your private key and can view it or provide it to you at anytime, that's no different than storing passwords in plaintext.

The keypair AWS generates can only be downloaded once, at the time of instance creation. Beyond that, they expect you to be in possession of the keypair when launching another instance that uses the same keypair. If you happen to lose the file, you're basically out of luck. So to directly address your concern, you can't download the keypair at any point in time, it's just a one time thing. To me that seems much more…

I much prefer DigitalOcean's option of no root password and letting me upload my public key. There's no need for them ever to know my password or private key.

Re: Passwords in plain text

#83

Post by astazangasta »

Why are we still doing this? We've known how to do secure authentication without the remote end holding your secret for years via public keys. Everyone here likely does this every day with ssh. There is even a browser mechanism for generating personal certificates for web authentication. The correct long term solution to this ought to be making this solution more intelligible and accessible to users. To hell with passwords and password exchange. They are a huge bug on the internet.

Re: Passwords in plain text

#84

Post by Daiz »

TomGullen wrote: post #57
Daiz wrote: post #39

Should really start doing this for sites using MD5/SHA1 for password hashing too, as using them is barely above plain text in terms of security these days.

> as using them is barely above plain text in terms of security these days How so?

Cracking them is so fast these days that they don't offer much in terms of security. For example, take a look at this post:

http://www.troyhunt.com/2012/06/our-password-hashing-has-no-...

Then note that it was posted two years ago. GPUs surely haven't gotten any slower since then.

Re: Passwords in plain text

#85

Post by hackinthebochs »

jonahx wrote: post #69
fooyc wrote: post #62

Earlier quoted context omitted.

I agree that from a security standpoint it's better not to send the password in plain text at all. But then you can start listing non-HTTPS sites, too. You disclose your password in plaintext to many servers every time you login on those.

Those should be listed too. I'm not sure I follow your point: Because there exists this other really bad but common practice, why are we harping on this bad practice?

Being overly concerned about having your email sniffed as its passed along internet peer is just misplaced anxiety. Anyone who can successfully sniff your password from your email in transit can already own if they chose to. The convenience factor of having your password emailed and having a record of it in many cases trumps this concern.

"But what if someone hacks your email, they know all your passwords!"

What if someone hacks your 1password account? It's the same exact scenario. Having a single point of failure that one can be extra vigilant with guarding is much better than the alternative of having a hundred unique passwords one must remember.

Re: Passwords in plain text

#86

Post by [deleted] »

omervk wrote: post #24
runn1ng wrote: post #21

Earlier quoted context omitted.

You are also listing websites that send you your password when registering or changing password. I am not sure that's appropriate. I know systems that send you the mail with your password after registration/password change and then save the passwords to database hashed. You cannot deduce that they save passwords in plaintext because they send you the password after registration/password reset. Example: http://plainte…

Yes, this is also explained in a link from our About page here: http://plaintextoffenders.com/post/7006690494/whats-so-wrong... TL;DR - it's still a security issue (albeit smaller), we've included it in our mandate, please don't do it.

[deleted]

Re: Passwords in plain text

#87

Post by fredsted »

ytch wrote: post #19
Myrannas wrote: post #10

Its a little scary how big that list is. My concern is that this is a great source of websites with poor security for potential hackers to exploit.

That's why we should use different passwords on each website

Thankfully password managers and software like iCloud makes this extremely easy. There's no excuse to not do it!

Re: Passwords in plain text

#88

Post by Daiz »

omervk wrote: post #64
Daiz wrote: post #39

Should really start doing this for sites using MD5/SHA1 for password hashing too, as using them is barely above plain text in terms of security these days.

How would one gather that information? What form of evidence would you accept? We'd like to refrain from asking people to hack into sites just to figure out their hashing scheme :)

It is harder than with plain text, yes, but it can show through at times. For example, a while back I was looking through my profile settings on a forum I have an account on, and saw a "check password security" link on it. Out of curiosity, I clicked it, and was greeted with "if a Google search for [unsalted MD5 hash of your password] returns results, your password is not secure." I reported it to the site and turns out it was a leftover from their old system, and it got removed shortly after (along with the MD5 password hashes).

You could also always ask too. I was reading through the forums of another site and stumbled upon a thread of someone asking HTTPS support for the site. The staff was pretty reluctant about the idea, which made me wonder about other security concerns. Looking around a bit, I noticed that the site cookies contain a "pass" value that looks very much like an MD5 hash. I got someone who used to be staff to ask the current staff how passwords are hashed, and the answer was "salted MD5".

Also, why is my initial post getting downvoted? Generic hashing algorithms are built for speed, which is bad for passwords. Key derivation functions exist for a reason. Hell, just a while back there was a user database leak from a site called MangaTraders, and they used unsalted MD5 for password hashing. It didn't take long before the vast majority of passwords had been cracked.

Re: Passwords in plain text

#89

Post by agildehaus »

marcosdumay wrote: post #79
kremlin wrote: post #26

Earlier quoted context omitted.

There's a fairly trivial way to do it in Django I think (whether it's still safe to send an email with pw in plaintext is still questionable at best): Say a user forgot their password and they click some link to reset their password: Generate the password text, then create an email with that password, send the email, and then store the password, connected to the User object, in the default Django way, which is SHA'd.

The Django builtin functionality is more secure than that. Do not send passwords in email. You should create a token, and mark the account with it, send the token to the user, and if the user sends the token back to you (at the URL, normally), you let him replace his password. The password itself is never communicated back to the user.

And be sure to destroy the token immediately after the user resets, and also after a reasonable time period regardless if it was used (24hrs seems fine to me).

Otherwise the email could be found later and used to gain access.

Re: Passwords in plain text

#90

Post by jedbrown »

aunty_helen wrote: post #36
CiaranMcNulty wrote: post #14

Earlier quoted context omitted.

Even if it's not stored at their end in plaintext it's a security issue that it's emailed in plaintext.

There was an article on HN in the last week (or so) claiming that both inbound and outbound encryption of email was happening. http://readwrite.com/2014/06/06/google-gmail-encryption-fail... Correct me if I'm wrong but wouldn't this mean that only the email stored on the recipient's email provider's server was then unencrypted.

Unfortunately, STARTTLS is subject to service degradation attacks and it is very common for email servers to use unsigned keys. Simply enabling STARTTLS protects against passive attacks, but until email servers refuse connections that do not create a TLS session with proper certs, email will remain subject to MITM attacks. Meanwhile, this failure mode is a usability problem for email. My experience with notifying companies about insecure email practices has been extremely disappointing, even among those that should know better (like national labs and financial institutions).
Post reply on HN