June 14, 2021

8 million passwords posted online from German gaming website Gamigo

(LiveHacking.Com) – The German gaming website Gamigo was hacked in February and over 8. million e-mail addresses and passwords were stolen. The passwords, which were hashed, were dumped on to crypto-cracking forum InsidePro. Now, four months later, underground crypto analysts have broken the hash.

A user on the forum, who claims to have cracked the one-way hash, has decrypted 94% of the passwords. PwnedList,  a tool that allows people to check if their online accounts have been compromised, told Forbes of the decrypted password which contains a huge 8.2 million unique email addresses. Of the 8.2 million, 3 million are from the USA , 2.4 million from Germany, and 1.3 million from France.

For those that aren’t familiar with Gamigo, it is a Massively Multiplayer Online Role-Playing Games (MMORPGs) publisher with a repertoire of 14 client games and five browser-based games. And obviously, it has over 8 million users worldwide.

After the original hack, back in February, Gamigo sent an email to its users which confirmed that there “was an attack on the Gamigo database in which user information, such as alias usernames and encrypted passwords were stolen.” All passwords were then reset for all Gamigo games.

While the decrypted passwords are unlikely to work on the Gamigo site, because of the forced password resets, users should check that they aren’t using the same username and password on any other sites.

In terms of size, this is the biggest cache of passwords stolen this year. Previously this unwanted honor fell to LinkedIn who had over 6 million passwords stolen.

Why Has Google Released the Source Code For Two New Hash Functions?

Google has released some of the source code for the new CityHash family of hash functions. In the initial offering Google has published the code, with a friendly MIT license, for CityHash64 and CityHash128. These functions hash strings to 64-bit and 128-bit hash codes, respectively.

64-bit and 128-bit hashes are considered weak by today’s standards and as such Google say that these functions aren’t suitable for cryptography, but do work well for hash tables. The release of this code raises several questions: Why would Google develop new hash functions? Why only 64- and 128-bit? Are there more functions that Google are using and developing? Will CityHash ever be used for cryptography?

On why Google would create new hash functions, the simple answer is speed. Google processes huge amounts of data and every fraction of a millisecond shaved off runtime over heads is essential in keeping computing costs down. Google are claiming that “under real-life conditions we expect CityHash64 to outperform previous work by at least 30% in speed, and perhaps as much as a factor of two”. That is a significant speed boost for Google. What is also interesting is that Google mention optimizing the code for CPUs that are common in Google’s datacenters. This can lead us also to conclude that Google are turning their attention to hashing, indexing and probably cryptography functions using specialized hardware. It is not uncommon today for hackers to use the power of GPUs in cracking codes and part of that work is in the generation of hash tables using GPUs.

As for the other questions, Google call these two functions “a family” of hash functions. Two hardly constitutes a family and in fact Google admit to using “variants of CityHash128” internally. It is most likely that Google have CityHash256, CityHash512 and CityHash1024 tucked away somewhere. If this is so, then these new functions could have a future in cryptography.

OpenSSL Released a New Version and Fixed Two Vulnerabilities

OpenSSL has released version 1.0.0.c of OpenSSL SSL implementation. With reference to OpenSSL security advisory, the following security issues have been fixed in the new version:

OpenSSL Ciphersuite Downgrade Attack

A flaw has been found in the OpenSSL SSL/TLS server code where an old bug workaround allows malicous clients to modify the stored session cache ciphersuite. In some cases the ciphersuite can be downgraded to a weaker one on subsequent connections.

  • The OpenSSL security team would like to thank Martin Rex for reporting this issue.
  • This vulnerability is tracked as CVE-2010-4180

OpenSSL JPAKE validation error

Sebastian Martini found an error in OpenSSL’s J-PAKE implementation which could lead to successful validation by someone with no knowledge of the shared secret. This error is fixed in 1.0.0c. Details of the problem can be found here: http://seb.dbzteam.org/crypto/jpake-session-key-retrieval.pdf

Note that the OpenSSL Team still consider our implementation of J-PAKE to be experimental and is not compiled by default.

  • This issue is tracked as CVE-2010-4252

More information is available here.


Related Articles: