31–40 of 179 posts
Earlier quoted context omitted.
The one that Apple's browsers request on every domain isn't even in the list: /.well-known/apple-app-site-association That's the only .well-known request we have in our logs from the last year or more. Seems to be looking for an app associated with our site. Aside from that, I don't know anyone or anything else using .well-known. Seems to be an Apple thing.
I think LetsEncrypt uses it, no?
https://github.com/ddevault/pass-rotate/issues/1
I hope a spec gains traction.
Seems like a nice subtle way to hijack the changing password mechanism, particularly on a sub-domain you control. Just set the URL to e.g. " https://evilsite/changepasswords" and wait for Password Managers to be updated. The fact that the spec says nothing about where a user can be redirected, and which domains/sub-domains are within scope for which change password requests seems like an oversight. For example if my…
Why bother redirecting the user to a third party site when you can just inject some password-logging JS into the _legitimate_ change password form?
That looks like a good idea, but why not go one step further? Provide a common API interface for password changes. Think about it: If you assume your pw manager database is compromised - what do you do? Go to a hundred webpages and change your password? probably not. Your PW Manager can't provide a feature to do it for you. But it could if there was such an API.
Why not? Complexity.
Seems like a nice subtle way to hijack the changing password mechanism, particularly on a sub-domain you control. Just set the URL to e.g. " https://evilsite/changepasswords" and wait for Password Managers to be updated. The fact that the spec says nothing about where a user can be redirected, and which domains/sub-domains are within scope for which change password requests seems like an oversight. For example if my…
I don't understand your concern. If the attacker controls ` https://example.com/.well-known/change-password` wouldn't they also control ` https://example.com/my_profile/settings` ? Why bother redirecting the user to a third party site when you can just inject some password-logging JS into the _legitimate_ change password form?
Seems like a nice subtle way to hijack the changing password mechanism, particularly on a sub-domain you control. Just set the URL to e.g. " https://evilsite/changepasswords" and wait for Password Managers to be updated. The fact that the spec says nothing about where a user can be redirected, and which domains/sub-domains are within scope for which change password requests seems like an oversight. For example if my…
I don't understand your concern. If the attacker controls ` https://example.com/.well-known/change-password` wouldn't they also control ` https://example.com/my_profile/settings` ? Why bother redirecting the user to a third party site when you can just inject some password-logging JS into the _legitimate_ change password form?
It is undefined behaviour. The spec is under-defined. That's my issue, there has been no security pass of this at all. It is left up to each individual password manager to make this secure (or not).
Earlier quoted context omitted.
Why not? Complexity.
I'd argue this reduces complexity by standardization. Having one system that is used among many sites allows easier verification of potential security pitfalls in that.
They say that iCloud Keychain on iOS 12 and Safari 12 have implemented this feature. And sure enough, https://www.icloud.com/.well-known/change-password Looking through the referenced RFC, there's a whole raft of "well known" urls that are registered https://www.iana.org/assignments/well-known-uris/well-known-... How widely adopted are these?
The one that Apple's browsers request on every domain isn't even in the list: /.well-known/apple-app-site-association That's the only .well-known request we have in our logs from the last year or more. Seems to be looking for an app associated with our site. Aside from that, I don't know anyone or anything else using .well-known. Seems to be an Apple thing.
That looks like a good idea, but why not go one step further? Provide a common API interface for password changes. Think about it: If you assume your pw manager database is compromised - what do you do? Go to a hundred webpages and change your password? probably not. Your PW Manager can't provide a feature to do it for you. But it could if there was such an API.
On that note though, if we start using standard APIs for this sort of thing, I question whether we should just go farther and "solve" the problem. Ie, as a dumb example, why should I expect them to implement an API for my password manager, and instead not simply allow oauth where my pass manager becomes my token provider? Doesn't that fake example solve both problems, while also getting rid of bizarre password churn?…
> simply allow oauth where my pass manager becomes my token provider
to be a simpler implementation then "PUT https://blabla.com/change-password" or whatever a password change request would look like?
seriously though, I would love this for all those sites that bury it as far as possible...