Tightening up security for an upcoming app idea

I know that I can use Crypt::encrypt and Crypt::decrypt which utilises the key stored in the .env - is this enough security inside the application itself, or are there other things that I should look into?

Yes, that will handle the encryption of data. You can also use the encrypt() and decrypt() helpers (which do the same thing).

Of course, there are other security considerations beyond encryption. Laravel helps you with several things, such as CSRF protection on forms, using PDO for database access, escaping strings in Blade templates, and helping you hash passwords (note passwords should always be hashed, never encrypted).

But Laravel can't do everything for you. Security is a complex topic. Here are a few thoughts:

• How will you keep your web server secure? Laravel Forge? ServerPilot? Handle everything yourself?
• How about your TLS configuration?
• Will you use a content security policy (CSP)?

If you're building an app from scratch and you really care about security, you have a good opportunity to use a strong CSP right from the start. It is much harder to retrofit CSP to existing projects.

Some good tools for checking your site:

• Qualys SSL Labs
• Mozilla Observatory
• Sonarwhal

Also, what steps should I take when setting up a server for this kind of application - would something like AWS be a good option? I usually just use linux servers with mysql but looking to use a better stack as I feel like I'm using an archaic setup.

Stick with what you know, unless you have a specific need for something different. AWS is amazing if you need huge scalability, but otherwise you're just making life more complicated.

I do particularly recommend ServerPilot though. This will secure your server and set up a better stack: Nginx as a reverse proxy in front of Apache, great TLS configuration, HTTP2 and Brotli out the box...

Good to finally see you on here! Can pop upstairs to our office if you want ;)

I've used this before but not on Laravel 5.5 (issue open) https://github.com/delatbabel/elocryptfive it uses Crypt

@bashy Ah dude I wondered if you'd ever see me post on here, blows my mind we're in the same building haha.

I'll take a look at the suggestions and see what we can do. Can any of you see any immediate issues with what I'm proposing at all? Is encrypting multiple columns going to cause me some speed issues or will it be negligible?

Easy to get an idea and run before you walk so doing my best to do this properly :P

Encryption will always slow down your app a bit, but we're likely talking milliseconds here. From what you've described, it shouldn't be too bad unless one of your clients has a load of clients and you want to show all their data at once.

@andyjh07 2/3 years ago I saw you doing some Laravel work in the canteen so I guessed you'd be on here too :P

The other issue you have to think about with encryption is that you give extra time (now and in the future) to make sure when software changes that you have some way of upgrading the encryption. Sometimes in Laravel this changes upon release of new versions.

Encryption is only as strong as the key you have (storage and access to it).

@bashy haha ah yeah, that was my reptile genetics calculator :P I saw your laptop skin on Twitter a while back, was meant to tweet you to see where you got it as I'd forgotten.

This is true, this particular project needs a lot of thought overall. I'm going to look into how to really lock down a server and keep that key as safe as possible - If any of you guys have recommendations on securing linux or similar I'm all ears.

Thanks for the suggestions so far, really don't want to go down one path with this and then have to totally rewrite it haha

The only generic piece of advice I have for you is to not assume that just because your data is encrypted, it's gonna be safe from any attack.

For example, if you're using the same key to encrypt/decrypt all the data, an error in your ACL might allow a client to access another client's data. I've seen that happen in the wild and sometimes it's not an easy thing to fix. If you have a different key for every client, even if one manages to access data they shouldn't be able to, the most they'll get is encrypted data or garbled text.

This would also allow you to, for example, migrate a client's data somewhere else (potentially the client's own server) and you'd only have to share that client's key instead of your application key.

As with most things, the best approach will depend on the specifics of what you want to accomplish. It'll be easier to help out once you actually get started and run into specific issues or want to examine alternative solutions to specific problems.

@andyjh07 Haha, cool! Ah yeah, got it from here: https://www.wrappz.com/cat/custom-macbook-skins

Server hardening is tough but by default it's pretty secure. Depends how far you want to go with it.

@bashy haha thanks dude, much appreciated :)

@36864 Aye, I definitely don't assume it's safe from any attack because it's encrypted; but it's saf_er_ with the encryptions.

I have thought about trying to work out how to use unique keys for each user, but is there a simple way to pass each user's key on the request etc rather than using the global? I was originally going to use a trait to encrypt/decrypt.

It's hard to share anymore than I already have at this point in time: I'd like the details of users, those user's clients and any associated jobs/files to be encrypted so that they aren't plain text - one box ticked when it comes to security.

I'll also want to roll JWT or similar into it so the API can be consumed by an app.

Just want to get a little bit of a clear picture on a good place to start so I don't need to rewrite the app a couple of times - though sometimes that's required

For multiple keys, you'd need to store them in the database and retrieve them whenever you want to use them. If they're stored in the users table, you'll be getting them automatically every time laravel fetches the authed user.

Keep in mind, this may not be a requirement for you if you can lock down your authorization routine. Your data model seems simple enough that it shouldn't be hard to protect with a few gates or a package like spatie/laravel-permission. Just make sure to can('view', $post) instead of can('view', Post::class).

Can't help ya with JWTs, haven't used them myself.

@36864 If they're stored in a table, with a foreign key, does that not then make an obvious correlation with what user it belongs to? If only the database is compromised, they can decrypt everything right? But if one key was stored in the .env, and they didn't get access to that (just the DB) the data would be useless - right? I know it's a lot of what if's though haha.

Yeah I use Spatie's Laravel-Permission in a couple of projects already, works really well :)

No worries on the JWT, new ground for me too haha

You don't store the personal keys plain in the database, you encrypt those with your application key, so if your database leaks, your attacker still needs to get your application key before decrypting it.

@36864 oh... yeah, you totally just blew my mind with something simple hahaha. Good shout