7 ms·
Another interesting and, retrospectively, obvious idea I recently read about: Have a class 'CleartextPassword' around, which overrides all string-serialization
by tetha 8y ago
Another interesting and, retrospectively, obvious idea I recently read about: Have a class 'CleartextPassword' around, which overrides all string-serialization as either a sequence of *s, or a hashcode of the password. Suddenly the type system prevents security issues.
- 49bc 8y agoCool 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 agoThe 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 agoI’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 agoWhatever 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 agoThis 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 agoExactly. 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.
- Gibbon1 8y agoI've though would be nice if languages had a 'secure' type qualifier which prevents leakage when something goes out of scope. AKA, compiler will issue code to zero out the data in memory once it's out of scope. Extending that, passing a secure type to an insecure function should result in a warning at least. log_printf( password.cleartext()); // error log_printf( password.safehash()); // okay
- sigfubar 8y agoSuch real-world concerns can and should be modeled using types. Your comment reminded me of taint mode in Perl. https://perldoc.perl.org/perlsec.html#Taint-mode https://perldoc.perl.org/perlsec.html#Taint-mode
- Gibbon1 8y agoNot sure if types will force the compiler to do things like constant time comparisons and overwrite sensitive information as it goes out of scope. I think Java, C#, and C/C++ the compiler will decide that code to clear memory just before it goes out of scope has no side effects and optimize that code away.
- zenhack 8y agoYou can definitely rig up the erasure to happen in a destructor (C++) or Drop implementation (Rust). Convincing the compiler not to optimize it out is tricky, but many cryptographic libraries include that functionality. The c11 standard has a memset_s function with the right semantics, but there are other ways to implement it. Re: constant time operations, I don't know of any language or system that does this currently. But a while back I was kicking around the idea with a friend and we came to a design that I'm pretty sure would work. Never got around to implementation though; so many projects, so little time.
- chriswarbo 8y agoWe can absolutely use types to ensure that our algorithms are constant time, e.g. https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/almeida https://www.usenix.org/conference/usenixsecurity16/technical... We can use types to enforce the big-O runtime of our functions too, e.g. ensuring that a mergesort implementation runs in O(nlogn) steps: https://www.twanvl.nl/blog/agda/sorting https://www.twanvl.nl/blog/agda/sorting I have no idea about doing these things in Java/C/C++/C# though; anything we try to enforce can be trivially broken by `NULL` :(
- Rapzid 8y agoScott Wlaschin, of fsharp for fun and profit, has written/presented[1] quite a bit about utilizing the type system to prevent invalid states. Diff lang, but sim concepts. It was an epiphany to me and a concept I have at least tried to bring back to the ALGOL side where possible. [1]https://fsharpforfunandprofit.com/series/designing-with-types.html https://fsharpforfunandprofit.com/series/designing-with-type...
- jackweirdy 8y agoThis reminds me of an article by Foursquare about how they use Scala Phantom Types to ensure MongoDB queries are semantically well formed: https://engineering.foursquare.com/going-rogue-part-2-phantom-types-d18ece7235e6 https://engineering.foursquare.com/going-rogue-part-2-phanto...
- danpalmer 8y agoThe other great motivating example I’ve seen is an Amount type parametrised by currency as well as the numerical value, so that the type system can enforce that you don’t add two amounts of different currencies, or that to add, you have to also provide a correctly typed exchange rate value.