samiux

就 20# 那個 screenshot 而言, 數據顯然已經排序了, 就只得這麼少???
Charcoal99 發表於 2014-8-31 17:19

The said hacker provides a database dump to download but it seems that the dump is a partial of the database.

Samiux

arshum

In the first beginning, I assumed that the data is hashed or encrypted according to official wordi ...
samiux 發表於 2014-8-31 16:40

network bandwidth 唔影響 server 計數能力 ga wor...
無論 server 用 MD5, SHA1, SHA2 做 hash, 佢由 us reply 番去 hk 既 travel time 都一樣架?

留名學野

wdtech

其實呢, 如果popvote programming 班友係醒既, 佢可以係client side 先RSA (or other asymmetric key encryption schemes) 個HKID 同電話號碼再hash. 另一方法係用random salt. 但如果佢地真係醒既, 佢地做左都唔會話你知。

另外, 我對 "15,445M c/s" 係完全無興趣。我地擔心既係個 architecture 夠唔夠secure。一個好既implementation 對呢D所謂  "15,445,000,000M c/s" 其實無大影響。

"The cracking tools are not cracking the hash.  They are comparing the hashes instead." 呢方面同意, 因為係Point #2 我都有陳述。

"One thing that I should mention is that the HKID card numbers and telephone numbers are not hashed and they are stored in the database in plain text from the captioned hack."
個hacker 講啫, 無人知係唔係真係621 popvote d 資料。如果條友真係好似佢所講咁清高, 佢就唔會放左個似是而非既 encrypted 7zip 出黎。仲有, 呢個世界有D野叫做honeypot. 如果popvote真係implemented 佢所講既野, 理論係無可能有plaintext 資料係server。出現呢D笑料, 一係hacker講大話或真心膠, 一係 popvote講大話。呢一刻無人知。

"if the data is hashed with salt and transmitted via SSL, the data still can be cracked if the hacker can access the database.  The key is time and money.  With the help of oclhashcat, the time will be reduced a lot if working with suitable hardware. "
我係細果時都好迷戀"速度"呢樣野。但當你大過你就會明白, 黑白兩方係平手既。另如好真係好似你咁講到D algorithm, implementation 等 係咁脆弱，我諗你應該要仲驚過我, 因為最少起碼你EPC dollar 多過我.

"Cracking tools are comparing the hashes instead of cracking the hash, you should keep in mind about that."
唉, 本如想完, 但最終又要回帶 - 呢方面同意, 因為係Point #2 我都有陳述。

"If the web application uses SHA-256 as hash algorithm, the web application will response very slowly and it will looking like hang when it is busy.  "
不解釋: http://www.cryptopp.com/benchmarks.html

學下computer architecture. 學下 programming. 用人地寫出黎既野同自己親手做, 所學到既野同成就感係唔同嫁。其實我年紀係唔細, 所以有時係會長氣D。希望你地呢D後生既, 後浪推前浪

samiux

After reading your comment, I remembered that I have read a very interesting article - Speed Hashing (http://blog.codinghorror.com/speed-hashing/).  This article is written in 2012 but what he said is still valid today.  You may not agree with him but it is truth.

I hereby to quote what the author of above link said ("what he said" as below) to reply about bandwidth related or web application response time questions.  Meanwhile, it is not secure to do the hashing or encryption at the client side :

"If the web application uses SHA-256 as hash algorithm, the web application will response very slowly and it will looking like hang when it is busy.  "
不解釋: http://www.cryptopp.com/benchmarks.html

Speed of a checksum calculation is important, as checksums are generally working on data as it is being transmitted. If the checksum takes too long, it can affect your transfer speeds. If the checksum incurs significant CPU overhead, that means transferring data will also slow down or overload your PC. For example, imagine the sort of checksums that are used on video standards like DisplayPort, which can peak at 17.28 Gbit/sec.

But hashes aren't designed for speed. In fact, quite the opposite: hashes, when used for security, need to be slow. The faster you can calculate the hash, the more viable it is to use brute force to mount attacks.  Unfortunately, "slow" in 1990 and 2000 terms may not be enough. The hashing algorithm designers may have anticipated predicted increases in CPU power via Moore's Law, but they almost certainly did not see the radical increases in GPU computing power coming.

Hereby, I quote what he said to reply about hash algorithms security question :

"if the data is hashed with salt and transmitted via SSL, the data still can be cracked if the hacker can access the database.  The key is time and money.  With the help of oclhashcat, the time will be reduced a lot if working with suitable hardware. "
我係細果時都好迷戀"速度"呢樣野。但當你大過你就會明白, 黑白兩方係平手既。另如好真係好似你咁講到D algorithm, implementation 等 係咁脆弱，我諗你應該要仲驚過我, 因為最少起碼你EPC dollar 多過我.

Use bcrypt or PBKDF2 exclusively to hash anything you need to be secure. These new hashes were specifically designed to be difficult to implement on GPUs. Do not use any other form of hash. Almost every other popular hashing scheme is vulnerable to brute forcing by arrays of commodity GPUs, which only get faster and more parallel and easier to program for every year.

As I said before, if oclhashcat use with HKID card number policy, the cracking time will be reduced a lot.  It is because the HKID card number policy is too simple.

Right? Right? This means if your database containing all those hashes is compromised or leaked, the users are still protected – nobody can figure out what their password actually is based on the hash stored in the database. Yes, there are of course dictionary attacks that can be surprisingly effective, but we can't protect users dead-set on using "monkey1" for their password from themselves.

I am so sorry not to reply you directly.

Samiux

polarhei

回覆 10# Charcoal99


算式有兩種, 單向或對稱. 通常, 因為, 發起人要的, 只是數字, 故只有單向. 完成後要按政策銷毀.

dsscss

你SHARE既ARTICLE 幾好...
佢既意思係話加SALT都係唔SECURE...
但你要諗 0下 係基於 0羊 SITUATION 先...

就好似樓上某D師兄所講,
你要知道原本羅 0黎 做HASH個STRUCTURE係點排列...
舉個例子..
就算簡簡單單...
只係用ID_NUBMBER做HASH..
HASH(SALT || REVERSE(ID_NUMBER))
同HASH(SALT || ID_NUMBER)
都已經係兩回事...
後者你可以用TOOLS + HACKER既"直覺"..
咁 0岩 估中個STRUCTURE 就俾你CRACK到..
咁前者呢...

JUST MY 2 CENTS...

snoopy11hk

Did that website reveal how they encrypted voters' data?
Maybe there were duplicated hash sums....  ...
toylet 發表於 2014-9-1 21:46

did you study computer security before?

samiux

did you study computer security before?
snoopy11hk 發表於 2014-9-1 23:36

MD5 may has chance to have same hash.  Please refer to the article (http://blog.codinghorror.com/speed-hashing/) or googling :

A properly designed secure hash function changes its output radically with tiny single bit changes to the input data, even if those changes are malicious and intended to cheat the hash. Unfortunately, not all hashes were designed properly, and some, like MD5, are outright broken and should probably be reverted to checksums.

    As we will explain below, the algorithm of Wang and Yu can be used to create files of arbitrary length that have identical MD5 hashes, and that differ only in 128 bytes somewhere in the middle of the file. Several people have used this technique to create pairs of interesting files with identical MD5 hashes:

        Magnus Daum and Stefan Lucks have created two PostScript files with identical MD5 hash, of which one is a letter of recommendation, and the other is a security clearance.
        Eduardo Diaz has described a scheme by which two programs could be packed into two archives with identical MD5 hash. A special "extractor" program turn one archive into a "good" program and the other into an "evil" one.
        In 2007, Marc Stevens, Arjen K. Lenstra, and Benne de Weger used an improved version of Wang and Yu's attack known as the chosen prefix collision method to produce two executable files with the same MD5 hash, but different behaviors. Unlike the old method, where the two files could only differ in a few carefully chosen bits, the chosen prefix method allows two completely arbitrary files to have the same MD5 hash, by appending a few thousand bytes at the end of each file.
        Didier Stevens used the evilize program (below) to create two different programs with the same Authenticode digital signature. Authenticode is Microsoft's code signing mechanism, and although it uses SHA1 by default, it still supports MD5.

Update reason : fix typo