Wachtwoord als platte tekst
Deze plug-in "All-In-One Security (AIOS) – Security and Firewall" wordt naar eigen zeggen op meer dan een miljoen Wordpess sites gebruikt, en volgens security.nl slaat het wachtwoorden op in plain tekst in de database.
Wel zo makkelijk voor wie z'n wachtwoord vergeten is.
Niet zo leuk als iemand anders je wachtwoord gebruikt.
Een Duits bedrijf heeft voor het opslaan van wachtwoorden al eens een boete gehad.
Als jij dus (succesvol) inlogde als user=admin en password=g3h31m, dan stond er ergens een logregeltje: "2023-07-17 14:08: successful login: ip=12.34.56.78, user=admin, password=g3h31m".
Het is dus meer een lesje dat je dit soort data niet moet loggen, of eerst opschonen: "2023-07-17 14:08: successful login: ip=12.34.*.*, user=admin, password=****".
https://php.watch/versions/8.2/backtrace-parameter-redaction
https://www.php.net/manual/en/class.sensitiveparameter.php
Voor wie er nog wél in gelooft. :)
In dat geval heeft deze link ook zin, met een aantal zaken om niet te loggen:
Quote:
Data to exclude
Never log data unless it is legally sanctioned. For example intercepting some communications, monitoring employees, and collecting some data without consent may all be illegal.
Never exclude any events from "known" users such as other internal systems, "trusted" third parties, search engine robots, uptime/process and other remote monitoring systems, pen testers, auditors. However, you may want to include a classification flag for each of these in the recorded data.
The following should usually not be recorded directly in the logs, but instead should be removed, masked, sanitized, hashed or encrypted:
* Application source code
* Session identification values (consider replacing with a hashed value if needed to track session specific events)
* Access tokens
* Sensitive personal data and some forms of personally identifiable information (PII) e.g. health, government identifiers, vulnerable people
* Authentication passwords
* Database connection strings
* Encryption keys and other master secrets
* Bank account or payment card holder data
* Data of a higher security classification than the logging system is allowed to store
* Commercially-sensitive information
* Information it is illegal to collect in the relevant jurisdictions
* Information a user has opted out of collection, or not consented to e.g. use of do not track, or where consent to collect has expired
Sometimes the following data can also exist, and whilst useful for subsequent investigation, it may also need to be treated in some special manner before the event is recorded:
* File paths
* Database connection strings
* Internal network names and addresses
* Non sensitive personal data (e.g. personal names, telephone numbers, email addresses)
Consider using personal data de-identification techniques such as deletion, scrambling or pseudonymization of direct and indirect identifiers where the individual's identity is not required, or the risk is considered too great.
In some systems, sanitization can be undertaken post log collection, and prior to log display.
Never log data unless it is legally sanctioned. For example intercepting some communications, monitoring employees, and collecting some data without consent may all be illegal.
Never exclude any events from "known" users such as other internal systems, "trusted" third parties, search engine robots, uptime/process and other remote monitoring systems, pen testers, auditors. However, you may want to include a classification flag for each of these in the recorded data.
The following should usually not be recorded directly in the logs, but instead should be removed, masked, sanitized, hashed or encrypted:
* Application source code
* Session identification values (consider replacing with a hashed value if needed to track session specific events)
* Access tokens
* Sensitive personal data and some forms of personally identifiable information (PII) e.g. health, government identifiers, vulnerable people
* Authentication passwords
* Database connection strings
* Encryption keys and other master secrets
* Bank account or payment card holder data
* Data of a higher security classification than the logging system is allowed to store
* Commercially-sensitive information
* Information it is illegal to collect in the relevant jurisdictions
* Information a user has opted out of collection, or not consented to e.g. use of do not track, or where consent to collect has expired
Sometimes the following data can also exist, and whilst useful for subsequent investigation, it may also need to be treated in some special manner before the event is recorded:
* File paths
* Database connection strings
* Internal network names and addresses
* Non sensitive personal data (e.g. personal names, telephone numbers, email addresses)
Consider using personal data de-identification techniques such as deletion, scrambling or pseudonymization of direct and indirect identifiers where the individual's identity is not required, or the risk is considered too great.
In some systems, sanitization can be undertaken post log collection, and prior to log display.
Ivo P op 17/07/2023 15:22:03:
he wil je mijn password hier niet posten :-)
Hoezo JOUW password? Die is van mij, afblijven!