Hacker News Reader

Comment by LadyCailin | Hacker News Reader

In the programming language I’m working on, MethodScript, I’ve created a subclass of string, secure_string. The normal print value is “secure string”. Unlike somewhat equivalent classes in other languages, this is a subclass of string, which means it can be passed around opaquely to things that only accept strings, but then the functions that actually need to be aware of secrets can check for the subclass and call the special decryption method. The string is encrypted in memory, but this is really just obscurity, because the decryption key is there too. But it does prevent most logging from ever leaking the secret, including things like memory dumps. I wish mainstream languages had a feature like this, since MethodScript is still fairly far in the “toy” category for now.

View on HN

> the functions that actually need to be aware of secrets can check for the subclass

I feel like this is an antipattern in OOP. Shouldn’t the functions just be defined to take in parameters of type SecureString instead?

I think this violates the liskov substitution principle (https://en.m.wikipedia.org/wiki/Liskov_substitution_principl...). For example, how is the “length” function or “startsWith” defined on SecureString? It seems like either data would be leaked via side channels, or the behavior doesn’t really conform to the String specification.

Yeah, that's a decent point. To answer your question, it's as if it's the string "*secure string*" for the purposes of other string methods.

I think this is a good point, and perhaps worth considering, but in most of my thought exercises, it's worth it, owing to the fact that when I use SecureString in other languages, I find myself having to decrypt the string more often than I would like. I guess one could argue that this is a deficiency of the libraries and such that are used, rather than a deficiency of the fact that SecureString doesn't extend String. I'm having trouble recalling a specific example right now, but I know I've run into it before, because that's what prompted me to implement this many years ago.

> Yeah, that's a decent point. To answer your question, it's as if it's the string "secure string" for the purposes of other string methods.

That’s a problem because you are enforcing all your functions accepting normal strings to either have to check if it’s NOT a SecretString or to return some nonsense. For exemple a function that returns the 2 firsts characters without caring about secret string could be passed one as argument and return « *s ».

The Liskov Substitution Principle states that a function accepting an Animal (a String) should never care about wether it’s a Cat (a Secret) and don’t fear Animal (String) methods to return meaningful values.

.NET (and PowerShell) have something similar. Interestingly, Microsoft recommends not using them. https://github.com/dotnet/platform-compat/blob/master/docs/D...

I assume by certs and Windows auth they're implying the OS native stuff versus just passing those around in code, instead

The key difference though is that mine is a subclass of string. I am aware of these in other languages, but they can’t be used in place of strings.

Should be fairly straightforward to implement in say Python?

If it quacks like a duck…

Sounds similar to Powershell's SecureString, if you want to compare vs a non-"toy" equivalent.

In isolation, yes, but my version is a subclass of string, which adds another layer of functionality on top of the base feature set.

I fear that this design violates the so-called "substitution principle", which states you should be able to use instances of a subclass anywhere instances of the parent class are used. In this case, you have defined a default behavior, but I would argue it's degenerate, because the value of your subclass are all the same.

In general, it's better to design subclasses to be constrained versions of the parent. If you want to add functionality to a class you're better off using another technique like composition, or even just a simple utility method.

Another way to state the issue here is that a user of an encrypted string will always need to know that it is an encrypted string because the only thing cyphertext is useful for is feeding the decryption algorithm.

I don’t really see the value in considering it a subclass of a string. Without decryption, the only meaningful “string-like” operations on it are equality (well, even that’s assuming that like strings share encrypted values, or equality is stored in a separate property). Why even make it a subclass of string in the first place?

Reply on news.ycombinator.com