Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

the technical problem is "create secure tokens and distribute them in authenticated messages to N clients that have not established trust" whereas the business problem is "we want a user login system".


sort by: page size:

OK, the token security outweighs the usability.

The core problem is really that passwords suck and should never be the entirety of authentication. Time for hardware tokens! (admittedly there are some big problems when people lose tokens, but at least that's not a problem of insecurity ;-))

Could you elaborate on why you believe security tokens to be a bad idea?

What the problem with the physical token the cost, the configuration, or just lazy users?

Tech has changed _a lot_ over the past few decades. Auth tokens expire. I'd be interested to hear how you're planning to future proof your solution.

Yes, then you are shifting the security problem to securing the private keys for these identity tokens.

Use physical tokens. Passwords is not the future.

There is a depressing lack of open standards with these off-the-shelf physical tokens. It's unfortunate that a company's security can rely on the APIs of another company which could go bankrupt and disappear at any time.

Or (3) implement an universal TLS standard to abstract logins away into hardware tokens... but that's exactly what we have but don't use super-widespread. Estonia has demonstrated the solution scales easily into millions, Latvia is working on it, Finland as well and a few other countries, but they're 15 years behind from Estonia, rest of the world is at least two decades behind. I've always wanted to make wild predictions, now I can try, I think such personal hardware tokens will become wildly mainstream in 25 years, totally replacing passwords.

hardware token would be a solution

Whats wrong with authenticating multiple tokens and backing up the physical tokens?

I'd rather know that each token is unique and not wonder how many copies of the token exist.


You need an RSA token for each server you talk to as well. It's not a replacement for asymmetric cryptography.

I hold some tokens from a project I worked on for 2 years (I hold everything on-chain) and also from my own project which I built (and designed the signature algorithm from scratch) so it's hard to get more security than that.

People lose their tokens and need a way to recover their account access. People don't want to have to go into a physical branch to verify ID and reset it. The security of everyone suffers to increase the convenience for a few.

2FA token is the most obvious use case I can imagine. Otherwise you can do some programming practice. You are limited on IO though.

Ah. So it's not the use of cryptographic tokens per se that you're objecting to -- just that they're not generated and/or handled correctly.

I think the panacea is dedicated hardware that can produce secure tokens (a signed message) without having to expose my key to the machine I plug into. But existing systems still require that level of trust; I'm doing no worse than someone with a password typing it into a possibly insecure machine.

I wouldn't say it's BS. It's just not perfect.

The standard person today isn't capable of managing multiple secure tokens, and actually keeping them separate.

One smashed phone, and truly secure accounts would be lost forever, or require significant resources on the part of the provider to re-verify people's identities.


Authenticator tokens are pretty robust systems. I'd like to see more services start to make use of them.
next

Legal | privacy