I was wondering if OpenCart has risks of such fines?
Current and older releases of OpenCart seem to store password with sha1 with salt in md5. The Github master uses password_hash.
The source document points to the German cryptographic procedures which says md5 is not compliant and also warns against using sha1.
Also, would using a 1.5x or 2.x version of OpenCart be considered a security risk with risk of fines since they're no longer being updated? But are there any known vulnerabilities with older versions?
Ernie's/IP-CAM's version of 1.5.6.5_rc has some small changes for what some threads say are small SQL injection vulnerabilities. It also has changes to run on PHP 7.x. I wonder if using this version of 1.5.6.5_rc is in violation of GDPR?
Would continuing to use end of life PHP versions, 7.2 and older, also be considered in violation if they don't have anymore security updates?
News Article:
https://www.heise.de/news/DSGVO-Bussgel ... 54208.html
Source document for the fine:
https://lfd.niedersachsen.de/download/169169
Cryptographic Procedures:
https://www.bsi.bund.de/SharedDocs/Down ... 02102.html
Google Translate of the description of the fine from the source document:
Fine for operating a website with outdated software
I took a report according to Article 33 GDPR as an opportunity to check a company's website from a technical point of view. It turned out that the web shop application xt: Commerce in version 3.0.4 SP2.1 was used on the site. This version has been out of date since 2014 at the latest and is no longer provided with security updates by the manufacturer. The software used contained considerable security gaps, which the manufacturer had pointed out. Among other things, the security holes made SQL injection attacks possible. The manufacturer also warned against continuing to use version 3 of the software.
With SQL injection attacks, attackers can gain access to the access data of everyone registered in the application. This attack vector arises when not all entries that can be changed by the end user are masked in such a way that the database cannot understand them as commands. Without masking, the database executes any command with its own rights. In this way, entire database tables can be output or deleted. Shutting down the server may also be possible.
My investigations showed that the passwords stored in the database were secured with the cryptographic hash function "MD5", which, however, is not designed for use for passwords. A quick 'calculation' of the plaintext passwords would therefore have been possible. There are also so-called “rainbow tables” on the Internet, which can be used to read the password associated with a hash without any calculation.
In addition, no “salt” was used. Such a salt, which is generated individually for each password, extends a password and thus makes the systematic calculation much more difficult. The aim of the Salt is that the attacker has to perform a complete recalculation for each password and prefabricated rainbow tables become worthless. Without Salt, on the other hand, a common calculation for the entire downloaded database was sufficient.
Without appropriate security precautions, in the present case it would have been possible to determine the plaintext passwords and then try out further attack vectors with manageable effort. An attacker would have the passwords determined z. B. can test with the e-mail addresses also stored in the database and, if successful, cause considerable (consequential) damage.
The implementation of a salt function and a current hash algorithm designed for passwords would not have been associated with disproportionate effort for the company, especially if this functionality is implemented with newer versions of the software. This also applies to the elimination of known security vulnerabilities for which updates are available. Regularly updating the software is sufficient to close known security gaps and other weak points. This can be associated with procurement and implementation costs, which, however, generally do not represent a disproportionate effort.
The technical measures taken by the person responsible were therefore not appropriate to the protection requirements according to Art. 25 GDPR, so that I discovered a violation of Art. 32 Paragraph 1 GDPR. I imposed a fine of 65,500 euros that the company accepted.
When determining the fine, I was able to take into account that the company had already informed the persons concerned that a change of password was necessary before the fine procedure.
Securing passwords
The requirements for passwords are identical from the point of view of data protection and information security. The Federal Office for Information Security (BSI) provides constantly updated recommendations on its website and in the technical guideline "Cryptographic Procedures: Recommendations and Key Lengths" (BSI TR-02102-1). Since the recommendations can change due to more recent findings, this article only offers a snapshot.
Instead of a very efficient calculation function such as MD5, a cryptographic hash function specially developed for passwords should be used. In order to determine passwords through systematic trial and error (brute force method), significantly more computational effort is required for functions2 specially designed for passwords. Furthermore, an individual salt should be created for each password. This means that so much computing power has to be invested that it can become uninteresting to determine the passwords for the entire database.
However, there may be individual access points that are of particular interest to attackers. Above all, this can be administration access and access for prominent people. The weak point therefore remains the password chosen by the user. The rule here is that the password strength is significantly more influenced by its length than by its complexity (uppercase letters, lowercase letters, digits, special characters). However, longer passwords can also be determined with reasonable effort if they can be found in password lists. Users should therefore not use proverbs or quotations as passwords.
There are no hard and fast rules for the length and complexity of passwords. When a password is sufficiently strong also depends on the environment and the typical attack vectors. If, for example, access is blocked for a longer period of time after three to five incorrect entries or an additional medium is retained after unsuccessful attempts (e.g. EC card), a shorter and less complex password is sufficient.
In the case of high risks or sensitive data, multi-factor authentication should also be used. In addition to user ID and personal password, one-time passwords could be sent or security tokens could be used.
Further fine proceedings related to technical and organizational measures
Violations of Articles 25 and 32 GDPR also play a role in other proceedings, albeit often subordinate. In the absence of a legal basis, video recordings can violate Article 6 GDPR or Section 26 BDSG, and there can also be a violation of Article 25 GDPR if the areas in which people are moving or staying have not been pixelated. Contrary to Art. 25 Paragraph 2 GDPR, in such cases the person responsible has not taken any suitable technical measures by presetting that only personal data are processed, the processing of which is necessary for the respective specific processing purpose. In such a case, the violation of Article 6 GDPR or Section 26 BDSG has priority.