Encrypt or not encrypt, that is the question



  • So I'm writing a sort of blogging app. Technically it's not "just" blogging, it's also for writing purposes, but some kind of personal journaling would certainly turn up.

    I'll be doing SSL from server to client, but what I'm curious about is the sanity of encrypting:

    1. data held on the server, which might include personal journals or partial novels, poems etc. which are all likely private (but user configurable to be public on occasion)
    2. data held in the client where using the local application cache to work offline

    Thoughts would be appreciated :)


  • Discourse touched me in a no-no place

    1: You can encrypt on the server if you wish, but the data isn't really all that valuable. If they were lots of patient data, or commercial engineering designs, or state secrets, yes, you'd encrypt. For a bunch of what is mostly going to be hack poetry? Being able to offer some sort of search function over a user's own submissions is far more likely to be useful, and that would make encryption trickier.

    2: There's literally no point in encrypting on the client.

    (This is all excluding login credentials. Encrypt those using usual best practices. And anyone writing poetry about their password is Doing It Wrong.)



  • What is it going to cost you to encrypt both anyway? If the encryption is totally transparent and has minimal impact on performance, you have nothing to lose and it becomes a good Marketing Point. Otherwise make it optional (at various / appropriate privilege levels of the implementation) and then it will no longer be "your" responsibility. Besides, having an optional "off" button is actually another Marketing Point.

    Encryption on the Server makes sense, and you would be foolish to assume or limit the type data that is going to be stored by the Users; the Server will be the (main) focus of any "attack".

    Encryption on the Client is almost the exact opposite: The User will not need to encrypt it from themselves, but you (or they) should not make the assumption that that will always be the case.

    If time and monetary costs are an issue, make it a V2.00 Feature or plugin (i.e. build in the hooks, I/F etc in V1.00) - which, again, improves the Marketing.



  • Unless you're doing per-user encryption where only the user knows the private key's password, server encryption is not really going to get you much. Disk encryption and the like make sense to protect against offline and some forms of side channel theft, but the primary attacks you're going to experience are going to be through online attacks, so either:

    1. they're in through the front door (i.e. some sort of interface bug), so the server will just give them the data in the clear anyway, or
    2. they're in through the back door (i.e. hacked server), and they'll just steal the keys on their way out.

    I disagree with @loose and say that device at rest encryption is more important than server at rest encryption. Your server will be on 24/7 so encryption doesn't exactly give you a lot unless somebody rips the hard disk out of the server. Generate a random AES key add it to the user's account. You can send it with the login response to decrypt their local data store.

    Given the type of data you are storing, I don't think you need either, but if it's not going to cost much, more security is always better.



  • Keep in mind that anything you encrypt also needs to have a decryption key somewhere. And if your server gets compromised, you've got bigger problems than "someone can read someone else's poems".



  • There are times when I wish you could make an anonymous post.

    This post is in no way a defence or rebuttal or in any other way, has any connection to my initial post.

    It would seem the the :WTF: topic derailment has reached a ludicrous point in record time. This argument of "don't encrypt on the Server because..." is effectively saying any encryption on any Server is pointless.



  • @dkf said:

    Encrypthash

    FTFY.
    Never encrypt passphrases. Always hash. (difference is encryption is usually reversible - we don't want that)

    @topic
    In your scenario it does not (imo) make sense to encrypt anything but the transport.
    If You really want to encrypt something, encrypt the data stored on the server. This will make a data leak impossible. (if the following things are done)
    Then you need to ensure the user stores xerses own key, and is able to restore that if their computer dies.
    You then need to de/en crypt clientside, to avoid having the key on the server.
    If a user makes a public post the client obviously has to decrypt everything and resubmit to the server.

    That's the only way it makes sense to me. If the users want encrypted local storage they'll have to do it themselves. (say full disk encryption)



  • Weak sauce pedantry, 3/10. So I FTFTFY:

    @swayde said:

    Never encrypt passphrases. Always use a cryptographic hash function. (difference is encryption is usuallyalways reversible - we don't usually want that)

    On topic:
    The cost(s) of key management probably outweigh the benefits in this particular case, but depends on the target users.


  • Discourse touched me in a no-no place

    @loose said:

    This argument of "don't encrypt on the Server because..." is effectively saying any encryption on any Server is pointless.

    It's not pointless, but it's not exactly valuable most of the time. What threat are you defending against by encrypting on the server? Physical theft of the server? Hacking in by the Russian mafia? Unethical employees?



  • @dkf said:

    Physical theft of the server? Hacking in by the Russian mafia? Unethical employees?

    Yes, yes and yes (and probably a few more to boot)

    Is it not a bit early on a Sunday morning to be laying out bait for the trolls, seeing as most of them have probably only just retired to their pits (nests / beds)? :rofl:



  • I had this same discussion with the one guy I work with, and the conclusion we came to was that encrypting on the server was mostly about convincing people it was "protected".

    Creative types tend to be protective of their stuff and I figured they might want to have "private things" that they want to put somewhere they can get to but no one else could.



  • I was just about to reply (again) to.... an individual. Along the lines of "my laundry list is very important to me, I want to store it where noboby can get at it, and if they could, they could not read it"

    :)


  • Discourse touched me in a no-no place

    @Arantor said:

    Creative types tend to be protective of their stuff and I figured they might want to have "private things" that they want to put somewhere they can get to but no one else could.

    That scenario is best solved by client-side encryption. Unfortunately, you also have to have the server store the key (ugh!) so that you can do recovery when the user forgets what they encrypted with. Or gets their computer wiped. But at least you can focus on making just that part highly protected, and it isn't much storage per user.

    As always, what is the threat model and how does it fit with the overall use model? Any time you are doing security system planning, that's the core question that you should be asking as it drives so many subsidiary decisions.



  • @dkf said:

    That scenario is best solved by client-side encryption.

    Wow, a new definition of "the cloud" - You keep all your shite on you PC in your home, and will keep the key for you in case you get locked out or lose your PC....no...wait....that means we will have the key to an "empty room"....hmmm....Ok....New Marketing slogan... "we can ensure the stable is safely locked, after the last horse has bolted"


  • Discourse touched me in a no-no place

    @loose said:

    Wow, a new definition of "the cloud"

    You've jumped the gun a bit there. In fact, you've gone all the way to jumping the laser gun attached to the shark. All I was saying is that you've got to figure out what you're defending against before jumping in with something half-assed and making things worse. Encryption for the sake of encryption runs the real risk of just preventing anyone from getting the data: it's safe, but the user is really upset…



  • Threat model is mostly perceived. Though I suppose if I screw up server configuration that could be a problem and if I screw up the platform that could be a problem.

    Fun fact: more than once people asked me if I'd write something to encrypt PMs in a certain forum platform, and I always refused on the grounds that 'if I'm the admin, I must logically be capable one way or another of decrypting it again because if the server can, so can I' followed by all the 'keep the keys on the client' / 'how do you encrypt it so it can be sent to different people while still working' type back and forth, while the core threat model was never realised by those asking for it.

    I'm fine either way, just thought I'd check the reality distortion meter in case it was broken ;)


  • Discourse touched me in a no-no place

    @Arantor said:

    Threat model is mostly perceived.

    Yeah. I get that. Virtually all actually good ideas have to be forced down people's throats against extreme resistance. Force of habit and institutional inertia is what keeps most things going.



  • Actually @dkf, I do agree with you, in principle, but I think you might be putting it wrongly. Stating that Servers should not be used to store your data securely, is a bit like stating you should not use banks to store your money securely (in my view). A bank will provide the same level of security for a £1.00 account as for a £1,000,000 account. It's is not the bank's role to determine the security level to be used. They could offer different levels, from none to maximum, but they should not make that decision on your behalf - that is the prerogative of governments :rofl:


  • Discourse touched me in a no-no place

    @loose said:

    Stating that Servers should not be used to store your data securely, is a bit like stating you should not use banks to store your money securely (in my view).

    No, you're still missing the point. Keeping the data encrypted is entirely possible, but then there's other things that you can't offer, such as searching and publishing to others. If you offer those extra services, the only thing you're getting from encryption is extra cost for operating the server, gaining the equivalent of putting the door key under the Welcome mat and pinning a note to the door saying “look under the mat”.

    Be clear what you're doing and why you're doing it, or you'll just do lots of dumb mistakes



  • Suggestion to OP: One way encryption of data into the permanent store:



  • That gives me an idea. I could use the ultra fast, ultra secure... /dev/null. It's better than being write-only!



  • This post is deleted!

Log in to reply