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

101–110 of 116 posts

Re: Passwords in plain text

#101

Post by TomGullen »

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.

Just a point, this is pretty much the same as sending a plain text one use password.

Re: Passwords in plain text

#102

Post by TomGullen »

Daiz wrote: post #84
TomGullen wrote: post #57

Earlier quoted context omitted.

> 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.

Same applies to all hash functions. It's how you implement it that counts.

Re: Passwords in plain text

#104

Post by TomGullen »

scottlinux wrote: post #100
TomGullen wrote: post #57

Earlier quoted context omitted.

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

See hashcat. :) It is easy to crack those types of hashes these days. Or even just search for the hash in google.

Same applies to all types of hashes. Implementation counts more than which function you choose.

Re: Passwords in plain text

#105

Post by __david__ »

joesb wrote: post #76
__david__ wrote: post #31

Earlier quoted context omitted.

> Using password reset links instead changes very little. Actually it changes a lot. Password reset links are one time only, and they get sent before you change your password. Mailing your password in plaintext after you've just changed it means it's good even if someone gets a hold of it months or years later. That's significantly worse.

Password can be one time password, too. Require user to change their password the first they login is not an advance feature.

Of course they can be, but that's not what we're talking about here. Please read the ancestor comments.

Re: Passwords in plain text

#106

Post by golem_de »

I say just mailman.

Anyone from Mozilla, EcmaScript, GnuPG and thelike here? Don't miss your monthly "password reminder" mail...

P.S. Just save ONLY a salted hash. Hash functions are designed to be one-way, so no one but you can re-store your password. EVER.

Re: Passwords in plain text

#107

Post by mnemonik »

golem_de wrote: post #106

I say just mailman. Anyone from Mozilla, EcmaScript, GnuPG and thelike here? Don't miss your monthly "password reminder" mail... P.S. Just save ONLY a salted hash. Hash functions are designed to be one-way, so no one but you can re-store your password. EVER.

I filed a bug and it was closed waiting for mailman 3 to ship :-/

Re: Passwords in plain text

#108

Post by ddebernardy »

oakwhiz wrote: post #92

I wish websites would actually use client certificate authentication instead of having to play hot potato with secret passwords.

This a thousand times. And ssh keys for servers.

But then, how would you log into e.g. gmail from a cybercoffee in a foreign country? (Assuming you dare do so in spite of the risk of key loggers.)

Re: Passwords in plain text

#109

Post by kremlin »

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.

I wasn't suggesting to do this and I have never done this, just pointing out that it is technically easy. I don't really know why I got a downvote for that

Re: Passwords in plain text

#110

Post by Excavator »

vijayaggarwal wrote: post #47
Excavator wrote: post #32

Earlier quoted context omitted.

Something like the Firefox Accounts¹ project? Which has Oauth2 support² in the works. 1: https://wiki.mozilla.org/Identity/Firefox_Accounts 2: https://github.com/mozilla/fxa-oauth-server

FxA is primarily for Firefox's own products and services. Mozilla Persona (confusing name - personas is what they called firefox themes as well) is closer.

Yea but there's really no good docs for Persona around anymore, that I can find.

The plan is to use Persona for ones FxA:

> One we get the basics down and enable single sign-on for relying Mozilla Services with your Firefox Account, we hope integrate Firefox Accounts with Persona on the Web and Firefox user agents to make logging in everywhere as painless as it should be.

Post reply on HN