|
|
|
|
|
|
by frio
4462 days ago
|
|
|
Security's something you do in-depth. You might build a perfect app, which correctly sanitizes your DB inputs (and you're right, it's easy these days). That won't necessarily stop $developer making a little PHP interface long after you leave, which exposes your DB again. I'm not up to the play with HMAC so can't confidently comment on that, but the point being made is that there is lots of SQL injection out there. Keeping the salt out of the DB seems like a not-insane way to help mitigate a compromise. |
|
|
Let me ask, does this hypothetical company have someone in charge of architecture, or everyone just codes randomly entirely on their own with no rhyme or reason until it works? Because that's what you're describing. Anarchy & chaos, with no one in charge.
The answer to the above hypothetical situation is that the PHP developer will code to the service layer, not to the database. In fact, that precise setup is very common in the projects I do: services (say in Java) consumed by delivery mechanisms (say PHP web sites).
Multiple independent apps reaching into the database directly is not only recipe for a security disaster, but a recipe for data integrity and maintenance disaster.
Here I explained service layers, so I won't repeat myself: https://news.ycombinator.com/item?id=7476725