Hacker News new | comments | show | ask | jobs | submit login

"That application whitelist probably needs a permissions flow for a user to agree that Password Manager Brand X is indeed their password manager application of choice."

This scares me. Are you proposing it as something that is necessary, or something that is necessary as part of the parent poster's suggestion to use HTTPS + PUT? If the former, how does this scale across the multiple platforms I use? Ugh. Scary.






I'm saying it as a baseline of something necessary to use HTTPS PUT for automated password change solutions, to keep them even reasonably safe. I don't want every possible application on the internet with the ability to change my password, so of course I want a whitelist of applications that could ever possibly do that on my behalf. That seems like one clear, important requirement to me.

You are right, it doesn't scale well.

To me (and one of the posters above) it's just more proof that password infrastructure in general doesn't scale very well (because security attack surface scales proportionally), and that we really need a better solution. "Simple password change HTTP PUT REST API standard" is a security nightmare, and we should all be afraid of the mere idea of it. We should instead be looking to get rid of passwords altogether, for something that maybe does scale better. Such as the suggestion above that it would be better to try to sketch an API that asks our password/token managers to log us in, rather than the other way around, like an SSH Agent or an OAuth/OpenID provider or some better standard we could attempt to devise.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: