Hacker News Reader

Comment by markokrajnc | Hacker News Reader

Passwords became hard to manage... now you have to choose >>different<< password for every site... Who can remember all those passwords? Only a password manager...

View on HN

We need to ditch passwords, not continue to proliferate them with sandboxed databases.

Yeah? What kind of a secret can replace a password/passphrase? Not biometrics, those are username replacements, not password replacements.

Keys. That are approximately equivalent to long passwords, but have a standard length, and do not need sending through the network. They are also something you have, that can be protected by a password for 2FA.

But that just won't happen. So many sites can not even accept big passwords, they won't all migrating to any sane schema.

They are password replacements in most contexts. The point of a password is usually just to verify your identity. Biometrics can do that just fine.

Biometrics are good replacements for usernames, but not for passwords. Biometrics can't be changed in the event of a breach, and can be taken from you surreptitiously or by force.

Yes, and those features are not necessary in most scenarios passwords are currently used.

Biometrics can be fooled, and even if they couldn't they can only verify your identity. They can't verify your volition.

They can be fooled now, but that is an implementation flaw, not a problem with the concept. I wouldn't cite the weakness of unsalted MD5 hashes as a problem with the concept of passwords.

I agree with your assessment of what biometrics can and cannot do. That is why I specifically said that in most situations, passwords are only used to verify someone's identity, and thus can be replaced with biometrics.

smartcards would be good for this.

Chip implants

How would that differ as a means of verification? It's not a known secret, just a different way of identification.

Not if the implant is writable. The xNT 13.56mhz NTAG216 RFID implant has 888 bytes of writable memory that could be used in this way.

It's really not hard. Generate passwords with 'pwgen -s 22' and store them in a gpg-encrypted file. emacs will prompt for your password when you open & when you save the file (there's probably vim code to do the same). Done.

It's not a completely ideal password manager, but it works.

If you can remember your password, then you shouldn't be typing it into a remote system, period.

That's really an awful solution compared to something like 1Password which has browser integration and synchronization between different devices. They even have a solution for groups.

Shameless plug time! Instead of remembering different passwords or using a password manager (and thus storing all your passwords somewhere) you can use https://salty.pw/

Problem with this is when you need a password with a capital letter, or with no symbols, or only 8 characters long.

Additionally, how do you determine the service name? e.g. I have a wordpress.com account; do I call that 'WordPress' or 'wordpress' or 'wordpress.com'? I guess using the domain name is fairly robust, but then you get stuff like Stack Exchange, or the service changes its domain name, or international variants - google.com vs. google.co.uk.

Yup, arbitrary restrictions on passwords are a bane. I've thought about adding various modes but then you need to remember the mode you used. So far the most sensible option seems to be falling back to a password manager for those sites.

As for the service name I've had no issues with that in my use. Just come up with whatever rule is easy for you to remember. Worst case you'll have to make a few tries.

fantastic!

now a site has been breached and your username/password was leaked... yay, you'll have to either start using a traditional password manager for this special case or change every.single.password.you.have.

so useful ...not!

Or you could change the algorithm and make it unique to you. A bit more technical but the point isn't to be ultimately secure, just more secure than your 'neighbors'.

An interesting idea. Any thoughts on how to use this on websites that force a password change periodically? Using a versioned salt maybe, although that could get tricky after a few iterations.

Thats cool! Does it use simple concatenation or HMAC?

It's simple concatenation. The exact algorithm is described at the bottom of the page so that one could reproduce it (and their passwords) independently.

What about taking the 128 MSB vs 128 LSB, is there any research into how secure that is?

I vaguely remember giving it some consideration. But the bigger point is that my judgement on these things is not to be trusted since I'm just an application developer and not a crypto expert.

Yeah thats the thing, I'm not a crypto expert either but I'd love to use it. But if it gets popular, and there is an accidental mistake that actually makes it easy to guess passwords, I don't want to risk that happening.

Good news. Did a bit of investigation, it seems like this could be vulnerable to a length extension attack [1] (though the attack its still pretty useless in this particular case) but it appears that truncating is both safe and takes care of length extension attacks! [2]

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

[2]: https://crypto.stackexchange.com/questions/18606/is-xoring-a...

Reply on news.ycombinator.com