Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
So I've given my User model an accessor/mutator that automatically decrypts/encrypts the user's name. This works great for the most part, but I've discovered makes user's names unsearchable in Nova - both in the Users resources, and globally.
In fact, searching for a snippet of the encrypted string as it appears in the database returns the associated user. Obviously this is not ideal. Is there any way to have Nova's search respect accessors? Or is my only option to switch to Scout?
Thanks in advance.
Nova is searching on the data that is in the database and I guess that is the reason why you think it is not respecting the accessor? That is the same as how Laravel behaves so I'm not sure how Scout will help you.
I don't see that point of your implementation, so can you explain?
Hey thanks for your reply.
I'd like user's names to be encrypted in the DB - it's good practice from a security standpoint, and gives us some cover in the event we're ever hacked or something horrible like that, god forbid.
I assume that Scout + Algolia could help by decrypting names before creating the index in Algolia, so that search would have access to cleartext values.
I know that Nova's default search & sort (without Scout) behaviour is to query the DB directly - I was just wondering if there was a way to override this so that it could decrypt data before searching/sorting. I know, this would mean the search/sort runs in PHP rather than SQL, but even so I'd be prepared to take the performance hit in order to be able to search/sort encrypted data.
Does that answer your question? Please let me know if I've left anything out.
So this implementation is created out of fear that you'll get hacked. If you get hacked, a hacker might be able to see the login credentials and use the UI to query the data and get real information about your users.
I would say that instead of complicating your implementations and everything you use, invest time into tightening the security so you don't have to live in fear. Laravel is pretty secure. Just keep things updated and educate developers not to make obvious mistakes and you should be fine.
Or if you insist on doing this encryption, I would advise getting a proper security advisor and doing things the right way. Few replies on some forums won't solve your problems.
Great suggestions! Absolutely, we're currently working with a security consultant and plan on engaging a pen-testing company to put our app through its paces before we launch.
I wouldn't say I want to encrypt our users' personal details "out of fear of getting hacked" - that's just one possible scenario. Surely it's just good practice to encrypt personal info where possible? There are any number of reasons why.
In any case, it seems like what I'm after isn't possible with Nova's default search functionality. I'll add moving to Scout to our bug tracker and let our support staff know.
Surely it's just good practice to encrypt personal info where possible?
Not really. But if you can name those practices I can give my input.
@bugsysha A lot of data leaks happen with backups, databases that are being transferred etc. It’s not uncommon a developer creates a dump of the production database to fix a specific problem that only exist for a specific user. I’ve seen this happen in small companies but also in companies with 1000+ employees. Now these dumps were for a short time on some devs local machine. Therefore it’s not a bad idea to encrypt user sensitive data in your database.
@Sauruz in my mind that is because things were not properly considered during the implementation phase and now logs, monitoring, security and a lot of other good practices are an after thought. With that approach company and developers will continue to struggle chasing things around and making worse and worse decisions along the way.
It's the first suggested example use-case in Laravel's own documentation for adding accessors and mutators to Eloquent models. If they're expecting people to use it that way then I'm probably not the only one doing it.
For example, you may want to use the Laravel encrypter to encrypt a value while it is stored in the database, and then automatically decrypt the attribute when you access it on an Eloquent model
(from "Eloquent ORM" > "Mutators / Casts")
Data encryption is also recommended by Azure for "data at rest", which includes DB storage. Anyway a debate about what constitutes security best practices is fairly far off topic! Thanks again for your recommendations.
@axiomatic I think you’re being over cautious and seems to be a case of “a little knowledge is a dangerous thing”. Sure, encrypt the database at rest, but not the data inside the database. As otherwise—as you’ve found—you essentially make your data useless and impossible to query effectively, thus destroying the point of using a database in the first place.
If you’re going to load your encrypted data into memory, decrypt it and then search it, you may as well store your data in a JSON file on disk and you’ll have exactly the same performance.
Data in a database can only be retrieved by connecting as a user and executing queries. The only servers that should be able to connect is the web server. If someone gets into your database server, they won’t be able to access the database because they won’t have the credentials. If someone has your credentials and access to the database server, well, encryption will do absolutely nothing for you.
Hey thanks for your response. Seems I'm getting a few people telling me that we're doing it wrong - I'll go back to our team and have a chat with them; perhaps we need to re-evaluate.
@axiomatic I wouldn’t say “wrong”. It’s obviously good to be conscientious of security, but encrypting All The Things™ can end up doing more harm than good.
Most services will encrypt at rest. That means the data on disk is encrypted; it doesn’t mean you have to encrypt the data going into a database, as that data by virtue will be encrypted if rest encryption is used.
Obviously there are some values you will want to encrypt, and may have a legal obligation to do so (things like government-issued IDs). But you probably also won’t be searching on these values; you’ll just want them when for example retrieving a single user and want to see their associated social security number or whatever. This is where you would use your Eloquent accessor to decrypt the value.
It seems like this earnest question got derailed by "should you" instead of answering the original question "can you". Short answer: No, Nova can't use your model to query encrypted data, but a custom tool could.
OPINION - Encrypted at rest does not mean the same thing to every security officer, I'm a CTO in Healthtech in Australia and they very much do mean encrypted in the DB, not on Disk. They literally are wanting to ensure that even the developer team can't read patient data out of the system. And you're right that's a PITA, but honestly I would expect the future to be more encrypted and security paranoid instead of less. - END OPINION
@axiomatic I actually came to this post for the same reason, I have encrypted patient data in a table, I had a bug where invalid syntax emails were allowed to be added to the system, so now I've got junk email addresses in a table that I can't read. Woot! Now, chatGPT suggests this can be fixed. I haven't had time to test it, but here's a "can you" answer instead of a "should you" debate: The high level steps would be:
As I said I haven't tested this, I didn't need it until now, but happy to hear from more experts on whether or not this method might work.
Please or to participate in this conversation.