Hacker News Reader

Comment by 49bc | Hacker News Reader

Cool idea. However It’s the DB that usually leaks the password, not the stack*

Assuming we’re talking about Scala and not C.

The issue isn't the stack, but rather an errant printf() or log() call — presumably, something like this would help with the issues that Twitter had recently.

https://www.theverge.com/2018/5/3/17316684/twitter-password-...

I’m pretty sure the Twitter fiasco was some sort of trace logging that logged every request body, and some of those requests happened to contain passwords.

Introducing a separate type for passwords doesn’t solve this issue.

Whatever the type was, it contained a password, and therefor could have been moved into a type that prevented the bug.

Whether it's a password or an "unparsed client data" structure or whatever.

This is going to be even more interesting if the EU keeps pushing privacy laws. Are you even allowed to trace productive unrestricted HTTP calls anymore?

I find this exciting from a problem-solving point of view, because for one, this is potentially a hard, ground-shifting problem. And on the other hand, languages like scala, haskell or rust have the tools to make this kind of requirements simple. There's an interesting time coming.

Exactly. Such a class doesn't secure the entire multi-container / multi-vm setup of a clustered web application, how could it? However, this is a simple layer of defense in depth, since it makes it harder for your application code to accidentally log out passwords.

And in a language with deconstructors, you can remove the secret from memory after it has been used. This in turn reduces the window of vulnerability against memory disclosure attacks, especially in shared virtualized environments.

Reply on news.ycombinator.com