7

At the moment I am working on a project that will handle some quite sensitive personal information, although it are not backaccount numbers it is still sensitive personal information and I want to do everything I can do to encrypt and store this information inside a mysql as safely as possible. So now I am intensely looking for some security measures that could deal with this sensitive information.

One easy way I found to encrypt/decrypt strings and text blocks, would be using mcrypt. But when I search on mcrypt over here on stackoverflow, I noticed that many people tell that mcrypt is afterall not that secure.

So now I am wondering, how secure is it really? Does it takes a lot of hacking skills, let's say expert skills, to crack and decrypt the stored information if the key is stored securely? Do I need to be afraid that a hacker with little skills can decrypt the encrypted information that I am going to store inside mysql server? So what skills does it take to crack the encrypted information that's encrypted with mcrypt?

If Mcrypt is not usable enough, what are good alternatives that are not to complex as using the gnupg extensions?

jonhopkins
  • 3,844
  • 3
  • 27
  • 39
Esocoder
  • 1,032
  • 1
  • 19
  • 40
  • 4
    Keep in mind the technology is only one part of the equation... your application must also be secure. Focusing exclusively on the technology can make you assume you are more secure than you are. – Jeremy Holovacs Jun 15 '12 at 13:49
  • 1
    *"i noticed that many people tell that mcrypt is afterall not that secure."* - not that secure? Is that without reasoning? – hakre Jun 15 '12 at 13:50
  • 1
    mcrypt itself is not a one-click solution, it supports several different algorithms in several different modes. It's a small cog crunching the actual numbers, around which you have to build your security system. Most of the time the insecurity stems from developers using mcrypt inappropriately because they do not understand the bigger picture. – deceze Jun 15 '12 at 13:53
  • Hakre, i do not know. I am pretty much new to encryption, so i can only find out by reading what others say about it. – Esocoder Jun 15 '12 at 14:12
  • Deceze, so in other words your telling that IF mcrypt is used properly it could be pretty much safe enough for usage? – Esocoder Jun 15 '12 at 14:13
  • I found many searches on stackoverflow people pointing to these class: http://stackoverflow.com/questions/2448256/php-mcrypt-encrypting-decrypting-file/2448441#2448441 Is this good way of making usage of mcrypt? – Esocoder Jun 15 '12 at 14:16
  • To trust information in a security context you don't understand properly, is not secure at all. So you should not listen to what others write. Just ignore everything you don't understand properly. Trust your own brain. Asking other's won't help you, so -1. – hakre Jun 15 '12 at 14:17
  • 2
    Indeed, I am not aware of a security flaw in mcrypt generally that would make it insecure. The very nature of cryptography though is that stuff is considered unknown until proven insecure. "No known vulnerability in mcrypt" simply means "so far so good, nobody has proven a vulnerability yet", therefore if used properly it should be of cryptographic use to you. This may all change tomorrow if someone publishes a vulnerability. Heck, maybe somebody is sitting on an exploit and is already using it as we speak, only that nobody has yet noticed... – deceze Jun 15 '12 at 14:23
  • 1
    By putting it this way I hope you understand the idea that there is a much larger picture that you need to know about and that the simple question "is mcrypt really secure" is hardly answerable. – deceze Jun 15 '12 at 14:25
  • 1
    Thank you deceze for pointing this out. Well since i am not a expert in encryption etc, i where worried because of what some others said. Maybe like hakre said, i should do some more research and use my own brain instead. – Esocoder Jun 15 '12 at 14:30

1 Answers1

16

A small guide you could follow to avoid a few pitfalls and apply some recommendations.

  • Do not reuse the same encryption key and initialization vector (IV) for two different messages.

Doing so will risk exposure of the plain-text if an adversary manages to intercept two or more messages during transit using the same key and IV.

  • Don't use ECB mode; OFB and CTR mode are somewhat better, but it's recommended to use CBC or CFB mode.

The main reason to not use ECB is because this mode leaks information about duplicate plain-text blocks which may undermine your encoded stream of data.

OFB and CTR are better, but they suffer from the aforementioned security issue of using the same IV+key combination more than once.

CFB and CBC are the most resilient against IV+key reuse, but separate messages with the same common prefix will leak out the length of said prefix. In addition, CFB leaks out the difference of the first non-identical plain-text blocks.

  • Make sure you have a strong encryption key

    It should not be chosen from printable ASCII (e.g. not "my super strong secret key"); PBKDF2 would be preferred (soon to be supported natively, until then Google it). It should be obvious that this key must be kept safe; if you lose it, bye bye data.

  • Use a good entropy source to generate the initialization vector.

    Mcrypt has an option to use MCRYPT_DEV_RANDOM or MCRYPT_DEV_URANDOM when you call mcrypt_create_iv().

Hope this will help you :)

Ja͢ck
  • 170,779
  • 38
  • 263
  • 309