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

A future without passwords

blog.google

Post reply on HN
Print view View original

221–227 of 227 posts

Re: A future without passwords

#221

Post by RamblingCTO »

bawolff wrote: post #193
RamblingCTO wrote: post #144

Earlier quoted context omitted.

> The biggest problem with passwords is that users select them, and users are stupid. I really hope you don't work with users or are doing anything that affects them. Users are not stupid, they maybe lack understand or are lazy and things are inconvenient. But the world is easier if you can just pass of your responsibility to the ominous "dumb user", isn't it?

I meant no disrespect to users as a group. Nonetheless its clear that we can't get >99.5% of ùsers to implement this security control properly, and that makes it a bad security control. And to be clear, its my belief that if someone implements a security control that constantly fails due to misuse, the party at fault is the implementor, not the user. Whether that's because users don't understand or just that their in…

> that makes it a bad security control

I agree. We can improve it so that others don't have to think about it and it actually solves their problem. Right now we pretty much just move the responsibility to the user.

Re: A future without passwords

#222

Post by mikedilger »

tialaramex wrote: post #125
mikedilger wrote: post #85

Earlier quoted context omitted.

If you don't have a google-enabled android device (as I don't), and you've registered your Yubikey with google (as I have), they won't use the Yubikey they will SMS you instead. Seems like they prefer google prompt, then SMS, then the actually secure stuff.

I just went to the bother to confirm that, exactly as I expected, Google just asks me for my Security Key when I sign in. This is what their UI says they will do, and sure enough it is in fact what they actually do. So whatever you're seeing is not in fact some sort of Google policy to prefer insecure SMS.

Ok. So it's not google then, it must be AWS or python-aws-google-auth (or my install of it.. which has python-u2flib-host enabled)

Re: A future without passwords

#223

Post by smsm42 »

I've seen several sites that don't have permanent password at all. You just tell them your email/phone no, and they send you the temporary password, which expires after the short time. Looks a bit unusual, but the security is not much different from any site that has password recovery by email/SMS - if somebody gets control over your email, you're toast, otherwise you're ok. I wonder why more sites don't do this...

Re: A future without passwords

#224

Post by whizzwr »

paranoidrobot wrote: post #91

I don't trust Google to fill this role of being arbiter of access to things. After it took me a week to recover access to a GSuite account that I knew the password for (long, unique, stored in a password manager), that I could confirm access via the recovery email, and that had my phone number attached - but Google were insisting that I was a hacker, and Support-robots refused to help me or assign a human until I fou…

Can you share the secret Konami code? Preparing for possible potential incident..

Re: A future without passwords

#225

Post by teitoklien »

hinkley wrote: post #13
tgsovlerkhgsel wrote: post #7

> Soon we’ll start automatically enrolling users in 2SV if their accounts are appropriately configured I get that this makes accounts more secure, but I'm more worried about accidentally getting locked out because my phone isn't charged/nearby/working than getting phished. I really hate it when sites take your ability to choose away, even though I understand why they do it. I wish the EU would regulate that sites mus…

So when my phone battery is dead and I try to log into my computer to tell everyone I’m going to be late, I can’t message them because my phone battery is dead. Awesome.

Everyday it feels , tech is going backwards instead of forwards :/

Re: A future without passwords

#226

Post by teitoklien »

forgotmypw17 wrote: post #50

The thing I like about the password is that it does not involve any additional technology dependencies. GitHub is going down this road, too, announcing that they will soon disallow password-based auth on git operations. I'm not sure if I will keep using it after that, because having to log into the website from every workstation, some of which may not even have a browser "good enough" for github.com, is more extra wo…

GitHub’s implementation is quite well tbh

They do allow you to generate OAuth codes with scoped access , which effectively acts exactly like passwords just giving more control to you and ensuring your account is safe.

I don’t think GitHub’s implementation is ill intentioned at all,

When compared to Google’s where it’s now effectively forcing me to keep using the gmail app Because of these prompts

:/

Re: A future without passwords

#227

Post by teitoklien »

smsm42 wrote: post #223

I've seen several sites that don't have permanent password at all. You just tell them your email/phone no, and they send you the temporary password, which expires after the short time. Looks a bit unusual, but the security is not much different from any site that has password recovery by email/SMS - if somebody gets control over your email, you're toast, otherwise you're ok. I wonder why more sites don't do this...

I guess to reduce friction for signing in

Most apps are not significant enough that people will go through the pain of checking their emails to get the new temporary password

Also , a lot of email clients still use STARTTLS while communicating with mail servers to fetch emails , which means a MiTM can reduce that connection to plain text (isp’s have been caught doing this before to read people’s emails) and then steal your password.

A site that enforces a rule like that must guarantee that its user’s email server only allows TLS only handshakes on client side (which is difficult if not impossible to do 100% of the time)

So even if the idea is great , due to the state email is in , it’s pretty risky and unsafe to MiTM attacks and network inspection.

Post reply on HN