101–110 of 277 posts
Closest to a password killer I've used so far is the built-in iCloud Keychain. My iPhone and MacBook both have access to the same passwords and most of the are randomly generated.
Earlier quoted context omitted.
Medium is frustratingly guilty here. Your login choices are limited to sharing data with Google/Facebook/Twitter or clicking a magic link in an email. If you don't like to share your data with third parties then you are basically restricted to logging in on devices that have access to your email. Which means you're stuffed when that doesn't apply. Security at the expense of usability is fine when it's warranted. All…
What about a throwaway email? Does that leak device data? (This whole thing reminds me of “Your post advocates a ... approach to spam. Your idea will not work. Here is why...” And maybe warrants a similar parody.)
So your only choice is to access your (personal) email on a device where you may not want/be allowed to.
I signed up for something recently and on the password screen it popped up with something along the lines of "Hey, can we generate a secure password for you, don't worry, your browser will remember it for you?" I said yes, sure enough a strong password appeared and Chrome offered to remember it. Seemed like a nice introduction to using secure passwords. The next thing I signed up for I manually generated a secure pas…
I signed up for something recently and on the password screen it popped up with something along the lines of "Hey, can we generate a secure password for you, don't worry, your browser will remember it for you?" I said yes, sure enough a strong password appeared and Chrome offered to remember it. Seemed like a nice introduction to using secure passwords. The next thing I signed up for I manually generated a secure pas…
And now that person is forever locked in to the browser they were using at sign up time. What happens if they move from Mac → Windows or Android → iOS?
Earlier quoted context omitted.
Sorry but I'm still not really following...where is the leak if it's hashed client-side? And the client will see the plaintext password regardless of whether there is processing or not. I guess what I'm asking is this: can someone walk me through the attack scenario? I don't really get it.
Consider: Mallory wants to access Alice's account on a website. 1. Mallory enters Alice's username and a random password 2. Website sends back Alice's plaintext password to be checked client side 3. Mallory inspects network traffic and retrieves Alice's plaintext password It's also bad if the hash is sent back; now Mallory can run all sorts of attacks on the hash itself without worrying about rate limits or any other…
As I recall, it did send you the plaintext password too, of course.
Ancient Egyptians probably made the same argument "Keys just won't work - everyone knows how to use a door knob, but these new dangled keys, no one carries them, we have not invented key rings yet so people will fumble. Best not to." No people dealt with keys and locks because they did not want their stuff stolen. As more and more valuable stuff is kept behind our passwords we will accept more and more cost to protec…
Keys aren't actually secure at all. Anyone with a lock-pick and a bit of practice can break in. I'd say that's actually about equivalent to a poor password—it's not that secure, but random person off the street won't be able to break in with a snap of the finger. Yes, with a password on the internet, there are far more possible attackers because you can attempt to break in from anywhere in the world. But that's somew…
Use at least one upper case letter and symbol
OR
Use a password that is at least 20 characters long
Passwords are fine, it's the differing standards that are nutty. Especially when you don't know them until after trying.
Earlier quoted context omitted.
Consider: Mallory wants to access Alice's account on a website. 1. Mallory enters Alice's username and a random password 2. Website sends back Alice's plaintext password to be checked client side 3. Mallory inspects network traffic and retrieves Alice's plaintext password It's also bad if the hash is sent back; now Mallory can run all sorts of attacks on the hash itself without worrying about rate limits or any other…
Wait why is the password being sent back by the server to the client? Is that what the commenter originally meant? If that's the case I completely misunderstood what they meant by processing the password with JavaScript. What you've described is insane; I thought the critique was in regards to processing a password locally before sending it to the server (e.g. local hashing).
> I've even seen a website where the password is sent to the browser and the password checking happens in Javascript.
i.e. the server sends the (plaintext or hashed) password to the client, and the client verifies it locally.
Edit: the original commenter replied as a sibling to you: https://news.ycombinator.com/item?id=18382949
If nobody understands anything other than passwords, how has 2FA taken off at all? How have password managers taken off at all? What if the password manager were in charge of logging you in _directly_, through some new protocol between browsers and PW managers? How could that _possibly_ be more friction? It would be strictly less. Hell, it could be done without even informing the user that this new feature was being…
Where does 2fa replace passwords? It's two FA after all. And I'd assert that password managers haven't exactly taken off; I'd be curious about their numbers, but the dozen or so people I know who use one are all software engineers. Also, they don't really replace passwords - they're based on them!
Password managers are a separate program that (some) people are willing to use as part of their login process. Perhaps whatever adoption it has is based on the fact that people understand passwords. But once they're used to using a program to log them in, I'd argue that's a potential hook into something more secure. Even something as simple as the API I described would mitigate (I'll stop short of saying eliminate) phishing attacks.
Earlier quoted context omitted.
It is generally always a trade-off between security and convenience. You can demand that a site allow passwords but you also aren't memorizing a 24 character nonsense password for each site login. The holy grail is can you bend the line and have something that is super secure and mostly convenient.
I currently work in an environment where I don't have access to a password manager, yet I am expected to have unique passwords for each service, and rotate passwords every month, and am not allowed to store passwords somewhere. Of course, this method requires you to remember more passwords than practically possible. If all accounts would have sane restrictions on the password it would become trivial to have something…
It may be you're working in the one environment where the master password + derived password scheme + counter scheme would be an improvement, but the above objection is why it doesn't work well for most users.