4 ms·

Cool idea. However It’s the DB that usually leaks the password, not the stack* Assuming we’re talking about Scala and not C.

by 49bc 8y ago

pdpi 8y ago
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-bug-security-flaw-exposed-change-now https://www.theverge.com/2018/5/3/17316684/twitter-password-...
- tzahola 8y ago
  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.
  - staticassertion 8y ago
    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.
    - tetha 8y ago
      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.
- tetha 8y ago
  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.

Cool idea. However It’s the DB that usually leaks the password, not the stack* Assuming we’re talking about Scala and not C.

by 49bc 8y ago

Cool idea. However It’s the DB that usually leaks the password, not the stack* Assuming we’re talking about Scala and not C.

pdpi 8y ago

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-bug-security-flaw-exposed-change-now https://www.theverge.com/2018/5/3/17316684/twitter-password-...

tzahola 8y ago
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.
- staticassertion 8y ago
  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.
  - tetha 8y ago
    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.
tetha 8y ago
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.