0

What does it mean when apps claim they encrypt at REST and HTTPS? I find this a little difficult to understand how different they are from the rest of the encryption-based Apps.

  • 25
    @GxTruth The term “encryption at rest” has nothing to do with the REST API architecture. – Mike Scott Feb 6 '18 at 13:09
  • 5
    @GxTruth actually I'd like to see an app developer use the term "encryption at REST" and see if the developer made this mistake ... – schroeder Feb 6 '18 at 13:20
  • 11
    Using all caps for REST makes this post much more confusing for some. REST encryption is a very different topic than encryption-at-rest. – Adrian Larson Feb 6 '18 at 18:19
  • 2
    @AdrianLarson yes, but that's the whole point of the question: there is confusion on that very point. This is inadvertently one of those "meta" questions where the question is itself the answer. To correct the capitalisation in the question is to fundamentally alter the question. – schroeder Feb 6 '18 at 19:36
  • 2
    PLEASE do not edit the question to change the capitalisation. To do so will only irreparably harm the whole basis for the question. – schroeder Feb 6 '18 at 21:27
19

HTTPS is one form of "encryption in transit", which means that data passing over the network to or from the application is encrypted. "Encryption at rest" means that the data the application stores on its local storage is encrypted, so that an attacker who can access the storage but not the application itself can’t read the data.

  • Perfect, Between don't all encryption based Apps do that ? I as a user would also like my local App data to be Encrypted. – WiredTheories Feb 6 '18 at 14:01
  • 3
    @OrwellIsRight it all depends on what the "encryption based app" is designed to do. – schroeder Feb 6 '18 at 14:13
  • 2
    @OrwellIsRight No, they dont. In the majority of cases a compromise in data storage also means a compromise of the application runtime (especially for apps running and storing data on the same physical machine). If the application runtime is compromised, encryption wont save you. – marstato Feb 6 '18 at 20:01
  • 1
    A perfect example would be a web browser. Even though a webpage is served over encrypted HTTPS, the content is often stored unencrypted on the disk-based cache. (@marstato In this example, code signing would help prevent compromise of the browser) – user71659 Feb 6 '18 at 20:12
1

HTTPS a protocol with which an application can communicate securely with a backend service, such as a database. It is the encrypted companion of another protocol, called HTTP. You've most likely seen those 2 protocols being used if you've ever used a web-browser on a Desktop machine.

When an application claims that it's using HTTPS, it's telling you that information you provide is transmitted using a secure, encrypted connection. This is especially important for sensitive tasks, such as credit card transactions, where a potential badguy otherwise would be able to eavesdrop and steal your creditcard information.

Thus HTTPS provides you with encryption in transit which leaves us to the next part.

encryption at rest is a term used by applications to notify you that they employ some sort of encryption scheme to protect the data that they store. Building on the example above, once your credit card transaction is complete, the app might ask you if they should save the provided information to make the next purchase quicker (I'm not quite sure that's okay if you want to stay PCI compliant, but bear with me here). If you agree, and the application claims to use encryption at rest, then you can be pretty sure that they encrypt the stored credit card details.

Please do remember that using encryption at rest does not mean that everything is encrypted. It also doesn't mean that the encryption in use is of sound design or is safe to use. Look for information where they specifically state what algorithms and ciphermodes being used. If they're willing to part with that information, you can be pretty sure they know what they are doing.

  • Mads, can you give an example of data which was encrypted using algorithms or ciphermodes NOT of "sound design" and resulted in a high-profile data breach? – daikin Feb 7 '18 at 0:26
  • @darkin: Many application used to (in the old days) store passwords hashed but not salted. Though the hashing was secure if you know one password and see its hash then you can determine any password with that hash. That would be an example of secure algorithm but not a sound design. Hopefully all sites have fixed this kind of issue by now. – Martin York Feb 7 '18 at 0:46
  • @MartinYork: Of course, that's assuming the people storing the password had even the slightest clue about hashing vs. encryption, which is surprisingly often not the case. – Kevin Feb 7 '18 at 3:49
  • @daikin: One example could be the broken encryption scheme in Office 97-2003: hashcat.net/forum/thread-3665.html and another one could be the Heartbleed vulnerability in OpenSSL which, if I remember correctly, was estimated to have cost 500million USD worldwide. – MadsRC Feb 7 '18 at 5:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.