Timeline for Is it a security issue to expose PII on any publicly accessible URL?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 9 at 19:46 | comment | added | Ja1024 | @marcelm: There are many different attacks with different consequences, and it defintitely makes sense to protect critical data even if parts of the application have been successfully attacked. If you disagree, then we can leave it at that. I don’t find this discussion particularly fruitful. | |
| Jul 9 at 19:43 | comment | added | Ja1024 | @marcelm: Nobody said anything about separate databases. I said database accounts. It’s very simple: Access to non-critical data should require less privileges, access to critical data should require more privileges. Your definition of “compromised” is also rather bizarre, especially since you seem to have the idea that server security is useless, because once an attacker has “compromised” the server, they can – according to you – do anything they want. This is obviously false. | |
| Jul 9 at 19:27 | comment | added | marcelm | @Ja1024 There's no reason to put the tokens and the PII in a different database. The web service that displays the order page needs access to both at the same time. Splitting out those two things gains nothing except complexity. And by definition, if that web service is compromised it has access to the PII. Accessing the PII and displaying it is what it does after all. | |
| Jul 9 at 18:37 | comment | added | Ja1024 | @marcelm: If an attack against the server immediately reveals the PII, there’s something wrong with the server configuration. The PII itself should of course be protected as well, e.g., by restricting access to a separate database account which isn’t affected by attacks against other components of the application. | |
| Jul 9 at 17:22 | comment | added | marcelm | @Ja1024 If the server is compromised, the attacker can see all the PII anyway. So I still don't see the point. | |
| Jul 9 at 15:04 | comment | added | Ja1024 | @marcelm: The point of hashing is that the tokens are safe even if the server is compromised. Without hashing, the attacker would immediately get all plaintext tokens. | |
| Jul 9 at 14:19 | comment | added | marcelm | "Instead, hash it with something like SHA-256 and store the result in the database." - I agree with using a unique secure random token instead of deriving it from the order id, but what's the point of hashing it in the db? | |
| Jul 9 at 7:52 | comment | added | le3th4x0rbot | Using UUIDs as random identifiers solves a lot of problems basically for free. | |
| Jul 8 at 15:27 | comment | added | Sjoerd | Using random tokens instead of encrypting identifiers is also the recommendation of Paragon. | |
| Jul 8 at 15:02 | history | answered | Ja1024 | CC BY-SA 4.0 |