1

Laravel documentation says

All of Laravel's encrypted values are signed using a message authentication code (MAC) so that their underlying value can not be modified once encrypted.

In practice it means that the payload is accompanied with a little hash value. It is not a secret of how this value is generated because Laravel is an open source product. The source code says this:

    // Once we get the encrypted value we'll go ahead and base64_encode the input
    // vector and create the MAC for the encrypted value so we can then verify
    // its authenticity. Then, we'll JSON the data into the "payload" array.
    $mac = $this->hash($iv  = base64_encode($iv), $value);

I personally don't see the benefit of this MAC for Laravel. Why is it there?

I mean, if we already have public key that goes along with the message and the private key hidden somewhere and openssl_encrypt as a processor. How MAC can contribute to the security? Or does it contribute to something else?

Yevgeniy Afanasyev
  • 37,872
  • 26
  • 173
  • 191
  • 2
    Suppose you didn't have a MAC. Now suppose an attacker gets a hold of the ciphertext somehow and changes one of the bytes. What do you think should happen when the modified ciphertext is decrypted? – President James K. Polk Aug 30 '18 at 22:05
  • I think decryption would fail. But if it would not... I will get an incorrect message. – Yevgeniy Afanasyev Aug 30 '18 at 23:55
  • 1
    There are two reasons can lead to this situation. Either it was an attacker or it was a machine failure. If it was an attacker - he would go to laravel source code and generate a new Mac using his change and I would not know I was hacked anyway. Or if it was a machine failure - most likely it will expose the problem. However In machine failure - there are lower level protocols that are responsible for this sort of control. Say If you use TCP-IP stack, then there would be `TCP/IP Checksum` in use behind the scenes. – Yevgeniy Afanasyev Aug 30 '18 at 23:55
  • 1
    For me it feels like - we hired a cleaner but we have never see him because he works at night. In some time we forget that we have a cleaner we hire another cleaner to work at night for us. – Yevgeniy Afanasyev Aug 31 '18 at 00:03
  • 1
    Depending on the mode used decryption would probably fail but might succeed. If it succeeds the unsuspecting consumer would be acting on bad information. In some contexts this could be devastating. A MAC uses the key, so an attacker cannot generate a correct one unless he has the key, at which point he has better options. An attacker may have a much easier time getting access to ciphertext than he would getting access to your source code. A MAC is needed to protect against intentional ciphertext modification. – President James K. Polk Aug 31 '18 at 00:16
  • My bad. It does use a secret key. OMG how did I miss it?!? Thank you, Thank you so much!!! – Yevgeniy Afanasyev Aug 31 '18 at 00:44

2 Answers2

1

There was a security issue in Laravel 3 where you could gain access as an authenticated user. Although this seems to be more cookie related (you could somehow forge them), but MAC was added then to the cookies.

http://joncave.co.uk/2012/10/lying-to-laravel/

TLDR In the future, it would be good to see Laravel’s Crypter class have MACs built in so that all encrypted messages are verified before decryption. Examples of this type of behaviour can be seen in Zend Framework 2 and Ruby on Rails.

https://laravel3.veliovgroup.com/docs/changes#3.2.8

This is because, decryption can be done with brute force, adding a MAC means you would do nothing if it doesn't matches what it should. The exact implementation of Laravel, i don't know how much security can add, but at least makes things harder for an attacker.

Erubiel
  • 2,934
  • 14
  • 32
  • 1
    Thank you, your links are really helpful. But speaking of Brute Force - MAC is generated out of 2 components - encrypted-message and iv. You don't even need to decrypt message to make MAC. It definitely would not make it harder for an attacker. – Yevgeniy Afanasyev Aug 30 '18 at 23:41
  • As long as MAC algorithm refreshes its value for each message it would be harder to brute force it. – Erubiel Aug 30 '18 at 23:49
  • Mac is not used for brute-forcing. You can ignore it when using brute force. – Yevgeniy Afanasyev Aug 30 '18 at 23:58
  • By what you say, i think you are talking of an already compromised server in which an attacker already has access. or i misunderstand completely ? – Erubiel Aug 31 '18 at 00:03
  • 1
    No, if it is not compromised server. if you have a message and you want to hack it - first you assume it is laravel, then you go to laravel source code an try to get payload out of it along with iv, than you use brute force to decrypt it and you totally ignore the MAC. Then you can guess a secret password and encrypt another message and on the way you would need to generate a MAC for it and you know how to do it because the MAC generating algorithms are public.No security benefits. – Yevgeniy Afanasyev Aug 31 '18 at 00:10
  • Have done this as proof of concept? it would be great to see how to do this, you left me intrigued! thanks for the info, i'll investigate more on the subject. In the meantime Maybe you can report this to Taylor Otwell on twitter... https://twitter.com/taylorotwell ... maybe some kind of customization could be added easily... – Erubiel Aug 31 '18 at 00:26
1

as James K Polk said

A MAC uses the key, so an attacker cannot generate a correct one unless he has the key.

A MAC is needed to protect against intentional ciphertext modification.

Yevgeniy Afanasyev
  • 37,872
  • 26
  • 173
  • 191