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

Why Login Security Sucks

matduggan.com

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Why Login Security Sucks

#51

Post by tptacek »

radicality wrote: post #30
tptacek wrote: post #8

Earlier quoted context omitted.

There is no less attractive use of blockchain tech than login. The biggest problem with login security isn't attesting to an identity, it's account recovery; blockchains make that incredibly difficult.

Fair enough, I guess for crypto wallets there isn’t any recovery that can be done if you lose the private key. In the end a cryptocurrency wallet is usually just a pub/priv keypair, so purely for login/identity purposes it’s similar to passkeys. And can be backed up easily. What I wanted to say is that hopping around different ‘dapps’ is quite seamless from a login point of view (and has benefits like ability to pay…

It's easy to make things seamless if you define away the corner cases!

Re: Why Login Security Sucks

#52

Post by lesuorac »

bqmjjx0kac wrote: post #40
lesuorac wrote: post #36

Earlier quoted context omitted.

I still cannot understand why mutual TLS never took off anywhere besides Gov [1]. You know how much more convenient it is to just open a browser and go to a webpage and already be logged in? [1]: https://en.wikipedia.org/wiki/Common_Access_Card

Wouldn't that broadcast a stable identifier to every site you visit?

Isn't that desirable?

Safari (Apple), IE/Edge (Microsoft), and Chrome (Google) all operate their own ad networks. I'm sure they'd love their own version of X-UIDH [1].

[1]: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

Re: Why Login Security Sucks

#53

Post by rlpb »

RadiozRadioz wrote: post #25

Controversial opinion: Username and password is perfectly fine. To provide an example that most people here are probably comfortable with: An SSH key is effectively a really long password with cryptographic properties. It's a single factor, one thing, that you use to complete a challenge for the server. We are fine to use SSH keys as our only authentication factor for servers, with IP whitelisting where security trum…

> We are fine to use SSH keys as our only authentication factor for servers…

Are we? True 2FA for ssh keeps getting easier. There’s FIDO2 support now for example. The gold standard includes 2FA and I don’t see why that shouldn’t continue filtering down to common practice, just as has already happened with ssh keys.

Re: Why Login Security Sucks

#54

Post by fragmede »

martinky24 wrote: post #9
radicality wrote: post #7

I know that crypto/blockchain is not super popular here, but the experience of logging-in to various dapps is pretty nice. The ”login” is the dapp showing the user a message to sign to prove they own the key, then you can sign the message, and that’s the whole login. There’s various ways to implement it, but here’s a quick tutorial for doing login with MetaMask. https://docs.metamask.io/wallet/how-to/sign-data/siwe/

Ah, the crypto industry known for being exceptionally secure in their practices, always vetting their security, and never cutting corners. We should do what they do. (Don't ask about what happened to the Ronin Network, Poly Network, FTX, Coincheck, etc, etc)

just like we have to separate the art getting the artist, we have to separate cryptocurrency from the cryptography. The underlying primitives are sound. Still not gonna factor 4096-bit keys any time soon, quantum computers won't be able break that for at least another decade.

Re: Why Login Security Sucks

#55

Post by wepple »

tomsmeding wrote: post #24
wepple wrote: post #15

> It is unclear why generating a one-time password for the user is bad but if we call the password a "recovery code" it is suddenly sufficient. The OTP is usually very long, highly randomized (you don’t get to choose Summer2024!), and designed to be stored offline somewhere as a break glass. Passwords typically follow none of those rules.

> highly randomized (you don’t get to choose Summer2024!) Sure. > designed to be stored offline somewhere as a break glass. That's fair. > The OTP is usually very long, No, 10 digits is not very long, that's just 10^10 (about 2^33). The xkcd password ( https://xkcd.com/936/ ) is better than that. It's better than Summer2024 perhaps, but not all that much better.

Sorry, when I said OTP I mean the recovery code OTP. They’re often 16 hex, so 16^16

Re: Why Login Security Sucks

#56

Post by wlesieutre »

RadiozRadioz wrote: post #39
wlesieutre wrote: post #32

Earlier quoted context omitted.

An SSH key isn’t exactly a long password since the service you use it for can’t leak your private key in a security breach

Yes, I deliberately didn't say it was _exactly_ a long password. I was more trying to get across the single-factor side of it. In any case, if the service handles passwords properly and the user generates one password per service (both wild far-out concepts unfortunately), leaking the salted hash would not matter.

Agreed, but it’s nice to not have to trust a service to handle passwords correctly

Re: Why Login Security Sucks

#57

Post by joshka »

Many of the questions about TOTP lengths / timing / storage are covered in the Security Considerations part of the RFC[1]. This is written in fairly plain language. The meta answer is if you're implementing a security protocol yourself, you should always be reading the RFC for this sort of thing. If you're designing a library to implement a security protocol, you should document the parts that need to be implemented according to spec (e.g. storage / transmission / time / etc.).

[1]: https://www.rfc-editor.org/rfc/rfc6238#section-5

On a what can we do perspective. We actually need some higher level concepts in play than just the APIs. What you really care about is:

1. You can identify the user.

2. The identity used by the user doesn't have a single point of failure.

Passkeys solve only the first part. You want the browser to tell you that the user has synced the passkey to another place other than just the browser. Or you want some other way to remove the reliance on a single factor.

The problem you really have though is not everyone has the same ability to sync passkeys. For some apps giving you an email address is likely secure enough to satisfy requirement 2. I hate it being the primary option though - that's annoying AF.

Re: Why Login Security Sucks

#58

Post by [deleted] »

wlesieutre wrote: post #56
RadiozRadioz wrote: post #39

Earlier quoted context omitted.

Yes, I deliberately didn't say it was _exactly_ a long password. I was more trying to get across the single-factor side of it. In any case, if the service handles passwords properly and the user generates one password per service (both wild far-out concepts unfortunately), leaking the salted hash would not matter.

Agreed, but it’s nice to not have to trust a service to handle passwords correctly

[deleted]

Re: Why Login Security Sucks

#59

Post by fragmede »

lesuorac wrote: post #52
bqmjjx0kac wrote: post #40

Earlier quoted context omitted.

Wouldn't that broadcast a stable identifier to every site you visit?

Isn't that desirable? Safari (Apple), IE/Edge (Microsoft), and Chrome (Google) all operate their own ad networks. I'm sure they'd love their own version of X-UIDH [1]. [1]: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

that's precisely why it's not desireble

Re: Why Login Security Sucks

#60

Post by fragmede »

pieter_mj wrote: post #43
RadiozRadioz wrote: post #25

Controversial opinion: Username and password is perfectly fine. To provide an example that most people here are probably comfortable with: An SSH key is effectively a really long password with cryptographic properties. It's a single factor, one thing, that you use to complete a challenge for the server. We are fine to use SSH keys as our only authentication factor for servers, with IP whitelisting where security trum…

How much does the recipe of strict requirements limit entropy of the password or enhance its predictability (both are somewhat related)? More of a problem is password reuse for multiple sites, which is impossible when using SSH keys.

Not to admit to poor security practices in public, but I don't generate different ssh keypairs for every server I log in to. If each keypair represents one password, and we're never supposed to reuse a password, I'm in trouble.
Post reply on HN