Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

Saturday, September 23, 2023

Transition to a GDPR-Compliant SMTP Relay Service

On September 19, 2023, we switched to an SMTP Relay Service with high reputation and GDPR compliance. This move enhances the deliverability and security of outgoing emails from OTM. The blog post elaborates on the benefits and implications of this change. For detailed information, see here: https://lsp.net/lsp-net-news.html#smtp

Umstellung auf DSGVO-Konformen SMTP-Relay-Service

Am 19. September 2023 haben wir zu einem SMTP-Relay-Service mit hoher Reputation und DSGVO-Konformität gewechselt. Dieser Schritt verbessert die Zustellbarkeit und Sicherheit der ausgehenden OTM-E-Mails. Der Blogbeitrag erläutert die Vorteile und Implikationen dieser Änderung. Detaillierte Informationen sehen Sie hier: https://de.lsp.net/lsp-net-news.html#smtp

Monday, May 23, 2016

OTM Update version 7.7


OTM 7.7 is a technical update which brings all modules on which OTM is based up to their newest version. This includes the latest versions of SQL, PHP (version 7),  Apache (HTTP/2), and numerous smaller tools and libraries used by OTM.

For users, these updates will be mostly noticeable in terms of increased speed, security and system integrity.

In the resource pages, the protocol of the result file upload now includes the name that the uploaded file had before it was renamed according to the name of the source file.


In >Administration >Resource administration >Candidates, the email addresses of candidates are shown in order to ease the identification of invited resources in this list.

A few minor bug fixes and small features have been added as well.


Friday, October 17, 2014

"Poodle" vulnerability fixed


When Google researchers published their "Poodle" vulnerability report on October 14th, LSP.net took immediate action by fixing this security issue on OTM servers. OpenSSL has been upgraded to version 1.0.1j and the OTM webservers now deny connections via the deprecated SSLv3 protocol. As a consequence, Windows XP users surfing with the ancient Internet Explorer 6 are no longer able to connect to OTM resource and client interfaces.


Thursday, April 10, 2014

Heartbleed Bug

Half a day after the SSL Heartbleed Bug became breaking IT news on April 8, LSP.net had fixed this bug on the OTM servers.

Due to the fact that our servers have been using Forward Secrecy in the past, we are sure about OTM servers haven't been affected by the Heartbleed Bug. Nonetheless we decided to initiate a re-issue of the QTN.net SSL certificate which has been implemented on QTN.net earlier today.


Saturday, June 16, 2012

Major improvements in OTM security


Up to now, passwords in OTM have been stored in the database with encryption corresponding to the usual Internet standard, a cryptographic hash function similar to the MD5 message-digest algorithm. As a consequence, even if an intruder manages to access the list of passwords, these cannot be used. Hash codes require considerable can be effort to break – as long as the password is “secure”. A password like “amadeus” is not secure, because it can be decrypted easily using a dictionary attack. (“Dictionary” in this context refers to a list of previously identified passwords.) So in this case, security really does depend on the user.

We have changed this procedure for two reasons. First of all, it is important to minimize the dependence on the user. In other words, an encrypted password stored in the database should remain “unbreakable” even if it is not secure (such as in the case of “amadeus” mentioned above). Secondly, the rapid development of greater technical capacities by hackers - using specialized hardware, Cloud computing and improved methods - is a source of increasingly deep concern. The dictionaries available for such attacks are also constantly increasing in size and now comprise billions of compromised passwords. Thus even passwords previously considered secure, such as “Iwab033yrsB4” are no longer sufficient for higher standards of security.

The technical reason for this, to put it simply, is that the code generated during hash encryption (the “hash”) is too short. It comprises a mere 16 hexadecimal characters. Such code might look like this: 3dd891646eab094f. One character can assume 16 different values (0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f). This results in 18,446,744,073,709,551,616 possible codes. That sounds like a lot, but it’s not enough to defend against high-powered computers and dictionary attacks. Though not all hashes and their associated passwords can be stored in a dictionary, because this would make it quite enormous, but if a password is listed in a dictionary, it can be compromised in seconds, enabling the attacker to log into the system. There is an underlying issue to cause even greater concern: this huge number of possible hash codes is actually not a problem any more for specialized hardware or networks of computers today. According to the latest estimates, a brute force attack on a specific password (meaning the rote, systematic attempt of all possible combinations until the password is “cracked”) would take about four days with the right equipment. This is completely unacceptable, of course. The security of encryption methods rests largely on the fact that guessing takes too much time for an attacker. The used algorithm is simply too efficient. Calculating the hash value does not take long enough.


Therefore, we have improved OTM security on three levels:

  • The length of the hash code stored was increased to block dictionary attacks.
  • Password security no longer depends exclusively on the user’s entry.
  • A more cumbersome cryptographic method is now used to cause delays to make brute force attacks ineffective. 

>> The change poses no problem for OTM users, as there is no compulsion to create new passwords.


Our method comprises the following: First, the password entered by the user is recoded to the previous hash value by the old method. This hash is then extended with a secret, long character string (referred to as salt). Then this extended character string is encrypted with the SHA256 method and compared with the entry (already converted by us) in the database. If the comparison shows a match, the password entered was correct. Otherwise not.

Thus the user can continue to work with the old password, because we can already convert its old hash value to the new value in the database even if the actual text of the password is not known. The salt makes the database hash value independent of the complexity of the user’s entry. Altogether, the method slows the process quite a lot, though not in a way noticeable by the user, because it is only a matter of milliseconds. But for an attacker, this difference makes a brute force attack pointless. Instead of taking days to break a password, the thousands of billions of iterations required would add a century or so to the time needed for a successful attack. Moreover, the hash value saved is no longer a mere 16 characters, each with 16 possible values, but rather 64 characters with 16 values. This translates to 1.1579208923731619542357098500869e+77 possible values for the hash code. No dictionary attack can cope with numbers of that magnitude. Thus all three points of possible attack have been reinforced, dramatically improving password security.

The changes will take effect with the OTM version 5.6.5 update.


-----------------------------
For more information on the above topics, please click the following links:
MD5: http://en.wikipedia.org/wiki/MD5
Salt: http://en.wikipedia.org/wiki/Salt_%28cryptography%29
SHA256: http://en.wikipedia.org/wiki/SHA256
Dictionary attack: http://en.wikipedia.org/wiki/Dictionary_attack