In Laravel, how would one encrypt email address of users? Like, it should be only be decrypted by users credentials e.g password etc (which only he knows). But then question arise, how would then app send important emails to that user..?
If your DB is on the same server as your application, encrypt the EMAIL also has mostly zero benifit as you would store encryption codes also on the same server.
What are in your case "important emails"? For login, password reset you only require a HASH no encryption, storing hashes is the best for the enduser. As in case of matching hash you can get the the email from the request and send a email then.
You only require the email for notifications which you may want in your app make it possible to loginEmail != notificationEmail of a user and so only store that as clear text.
Still want toe encrypt something, have a look at: laraveldaily.com/post/laravel-encrypt-models-data-with-casts
They said "it should be only be decrypted by users credentials e.g password etc (which only he knows)"
Then "async" notfications are not a thing then. Which leads back my the original question: What are in that case "important emails"?
Not password resets, obviously. No longer possible because the user forgot their password and now the email can't be decrypted. I'm not sure what problem the original question is trying to solve but it introduces so many new problems it doesn't sound like it would be worth any effort spent on this. I would love to know more about the problem vs the proposed solution of encrypting the user email.
If you don't need to ever send emails then you could just hash the email just like you do with the passwords. If you want to still email these users you could put the hashmap on another server but still nothing secure about this. Just more complex.
What is the goal here?
I get that, but why still? Its basically public information. But besides that, the encryption idea will break any email based functionally you might want. If you store their key there is no point even encrypting them. If you don't plan on ever emailing them then you can just store a hash of the email which is infinitely more secure than any two-way encryption. This seems to introduce more problems than it would solve.
I personally would abandon the encryption idea. Instead, look at other ways to obscure their email address. For example, you could create a user@yourdomain.com and forward that to their real email. The user@yourdomain.com mapping could be housed on another server and be more secure than the main app. It's still not 100% - but nothing is. Even the encryption route has flaws and limits functionality.
It's an interesting question! Thanks for sharing it. Not trying to be negative at all, just want to fully understand and help solve the problem. Good luck!
You don't require decrypt the email for Password Reset if you just hash the email with a known application secret. This way you not require save plain email adress or even a decryptable Email adresses you just need find the matching user by a emailHash.
Pseude Code:
$submittedResetEmail = $request->query->get('email');
$hashEmail = SHA1($submittedResetEmail . $appSecretSalt);
$users = SELECT * FROM users WHERE emailHash = :hashEmail
if (count($users)) { // userHash found send reset email to:
sendEmail($submittedResetEmail);
}Thank you so much for letting me know about this possible way. Keeping users emails as private as possible can keep them save from many unwanted activities.
Ah, I see. That's a good solution! You never store the email in this method but when they put it in you temporarily have access to it for the reset. That info could still get logged so care would need to be taken so that it's not stored/leaked that way but this is a very cool solution. I've seen similar on migration passwords from old systems to new ones and I didn't think to apply it to this. Brilliant.
yeah migrations of passwords hashes to modern password algo like bcrypt works the same way :)
@alex_s_ I just recently used it to migrate an old phpbb 2.x forum to 3.x and then to Invision latest and that's exactly how we kept passwords working. Worked better than expected. The users were very happy.