3 ms·

> 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

by __zack 5y ago

> 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_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.

LadyCailin 5y 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. 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.
- pjerem 5y 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.

by __zack 5y ago

LadyCailin 5y 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. 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.

pjerem 5y 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.