Backdoor discovered in Ruby "strong password" library, takes your "strong passwords" and uploads them into a pastebin

Hi, do you believe me when I say we need ocap security yet

@cwebber I think this problem could have been solved with a purely functional programming language. Although the compiler would need an option to disable any unsafe* functions (like the ones in haskell).

Side-effects are really dangerous, this proves it.


@jorge_jbs Even purely functional programs *do* get access to side effects though, because you need to do do anything useful. They do it through a monad.

The question is: who gets access to that monad?

You're right that functional programming can help, but it isn't that the language is functional itself that does it, it's that it supports higher-order functions and the ability to pass around references.

@cwebber If the library's interface doesn't return any monad (for example, isPasswordStrong has type String -> Bool) then there is no need to give access to any monad, everything is pure.

This library seems like a good fit for a pure library. If it needed some types of side-effects (but not all) you could return the FileAccess monad, or something similar.

All the code has access to all the monads. Executing them is another story.

@jorge_jbs You may be right that this is protecting the right behavior/safety. The way you described it, you can only perform side effects if you've explicitly been handed the reference, does sound like exactly the reference-based-ocap-security stuff I'm talking about. That approach isn't limited to purely functional languages, but you've correctly identified a purely functional way to do it.

@cwebber I don't know how ocap works, but yeah, it looks we're saying the same thing but implemented in different ways.

@cwebber @jorge_jbs Indeed, you can even imagine pure functions leaking passwords in their output in non-trivial ways (= ways which cannot be easily seen by looking at the function definition).

@scolobb @cwebber If a functions leaks anything to the outside world aside from its result then it is not a pure function, by definition.

@jorge_jbs @cwebber That's why I said "leaks in its output", meaning that being pure and being secure are orthogonal things.

Imagine a trivial (and stupid) example: you have a pure function taking a string and an encryption key and simply concatenating the two: it leaks the original string in the output. Now, this is clearly a stupid example, but you can imagine insecure encryption procedures which do not obfuscate the input well enough, but which are still pure in the sense that they produce no side-effects.

I am not a security expert (I'm actually not an expert in almost anything 😄), so feel free to take my word with a big grain of salt or anything healthier than that 😉

@jorge_jbs @scolobb @cwebber
I could imagine pure functions leaking information about passwords via timing channels, CPU heat, fan rates, EMF levels related to frequency of RAM accesses, etc. Functional code eliminates state from the perspective of the programmer but in some respects only hides state that still exists from the perspective of physics.

@enkiv2 @scolobb @cwebber Well, you could make a functional language that abstracts over all the implementation details, so you couldn't rely on them. For example, the implementation could add noise so that it really is pure. But, in practice that sounds to be terribly slow xD. But, also in practice, you wouldn't leak side-effects that way.

@enkiv2 Yeah, indeed. These leaks are very hard to deal with, and should probably be handled in close cooperation between hardware and software. Choosing any particular software architecture is probably not enough here. (Thinking as I speak.)
Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!