Re:Tell HN: Security notice from Slack regarding Shared Invi...
by werrett on Friday August 05, 2022 @02:11AM
(#32352379)
While getting rid of passwords is admirable and advisable, I don't think it is the answer here. What happens when `JSON.stringfy` posts your fancy magic link token somewhere undesirable?
Applications will always need to generate, process, and transmit sensitive data. They 'just' need transit it to trusted places. Easy! ;)
Filtering data before it gets to untrusted sinks, or at least warning when it does, seems like a more generalizable pattern. The downside is you both need to know what's sensitive and go out of your way to handle it as such in basically any language or framework.
Cases in point: * https://www.google.com/search?q=java+avoiding+logging+sensit... * https://www.google.com/search?q=golang+avoiding+logging+sens... * https://www.google.com/search?q=python+avoiding+logging+sens...
The broader conversation I think here is facilitating a shift to passwordless. Magic links, OAuth, Yubikeys all make passwords redundant.
If I put in a password I still need MFA and I can reset my password with just MFA, so why do I need the password at all? Let’s just switch to MFA-only signon.
Slack kinda led the charge to magic links and passwordless so it’s strange to see they’re still stuck on this. Many enterprise orgs have moved SSO setups to enforce solely passwordless already.