I feel like I should comment some of the clams being posted as replies here.
For starters, speed IS an issue with MD5 in particular and also SHA1. I've written my own MD5 bruteforce application just for the fun of it, and using only my CPU I can easily check a hash against about 200mill. hash per second. The main reason for this speed is that you for most attempts can bypass 19 out of 64 steps in the algorithm. For longer input (> 16 characters) it won't apply, but I'm sure there's some ways around it.
If you search online you'll see people claiming to be able to check against billions of hashes per second using GPUs. I wouldn't be surprised if it's possible to reach 100 billion per second on a single computer alone these days, and it's only going to get worse. It would require a watt monster with 4 dual high-end GPUs or something, but still possible.
Here's why 100 billion per second is an issue:
Assume most passwords contain a selection of 96 characters. A password with 8 characters would then have 96^8 = 7,21389578984e+15 combinations.
With 100 billion per second it would then take 7,21389578984e+15 / 3600 = ~20 hours to figure out what it actually says. Keep in mind that you'll need to add the numbers for 1-7 characters as well. 20 hours is not a lot if you want to target a single user.
So on essence:
There's a reason why newer hash algorithms are specifically designed not to be easily implemented on GPUs.
Oh, and I can see there's someone mentioning MD5 and rainbow tables. If you read the numbers here, I hope you realize how incredibly stupid and useless rainbow tables have become in terms of MD5. Unless the input to MD5 is really huge, you're just not going to be able to compete with GPUs here. By the time a storage media is able to produce far beyond 3TB/s, the CPUs and GPUs will have reached much higher speeds.
As for SHA1, my belief is that it's about a third slower than MD5. I can't verify this myself, but it seems to be the case judging the numbers presented for MD5 and SHA1. The issue with speeds is basically very much the same here as well.
The moral here:
Please do as told. Don't every use MD5 and SHA1 for hasing passwords ever again. We all know passwords aren't going to be that long for most people, and that's a major disadvantage. Adding long salts will help for sure, but unless you want to add some hundred bytes of salt, there's going to be fast bruteforce applications out there ready to reverse engineer your passwords or your users' passwords.
PHP.mk документација
Хеширање на лозинки
Почист и полокален преглед на PHP референцата, со задржана структура од PHP.net и подобра читливост за примери, секции и белешки.
Патека
faq.passwords.php
Локална патека за оваа страница.
Извор
php.net/manual/en
Оригиналниот HTML се реупотребува и локално се стилизира.
Режим
Прокси + превод во позадина
Кодовите, табелите и белешките остануваат читливи во истиот тек.
Референца
faq.passwords.php
Хеширање на лозинки
Референца за `faq.passwords.php` со подобрена типографија и навигација.
Безбедно и сигурно хеширање на лозинки
Овој дел објаснува зошто се користат функции за хеширање за заштита на лозинките, како и како да се направи тоа ефективно.
-
Зошто лозинките што ги даваат корисниците треба да се хешираат?
-
Хеширањето на лозинките е една од најосновните безбедносни разгледувања што мора да се направат при дизајнирање на која било апликација или услуга што прифаќа лозинки од корисниците. Без хеширање, сите лозинки што се чуваат може да бидат украдени ако продавницата за податоци е компромитирана, а потоа веднаш да се искористат за компромитирање не само на апликацијата или услугата, туку и на сметките на корисниците на други услуги, ако тие не користат уникатни лозинки.
Со примена на алгоритам за хеширање на лозинките на корисникот пред нивното чување, станува неверојатно за кој било напаѓач да ја утврди оригиналната лозинка, додека сè уште може да го спореди добиениот хеш со оригиналната лозинка во иднина.
Важно е да се напомене, сепак, дека хеширањето на лозинките ги штити само од компромитирање во продавницата за податоци, но не ги штити нужно од пресретнување од злонамерен код инјектиран во самата апликација или услуга.
-
Зошто вообичаените функции за хеширање како md5() and sha1() се несоодветни за лозинки?
-
Алгоритам за хеширање како MD5, SHA1 и SHA256 се дизајнирани да бидат многу брзи и ефикасни. Со современи техники и компјутерска опрема, стана тривијално да се
brute force
излезот од овие алгоритми, за да се утврди оригиналниот влез.Поради тоа колку брзо може модерен компјутер да ги
reverse
овие алгоритми за хеширање, многу безбедносни професионалци силно се против нивната употреба за хеширање на лозинки.
-
Како треба да се хешираат лозинките, ако вообичаените функции за хеширање не се соодветни?
-
Кога се хешираат лозинките, двете најважни разгледувања се пресметковниот трошок и солта. Колку е попресметковно скап алгоритмот за хеширање, толку подолго ќе трае brute force неговиот излез.
PHP обезбедува нативна API за хеширање на лозинки што безбедно ракува со двете hashing and проверка на лозинки на безбеден начин.
Предложениот алгоритам за користење при хеширање на лозинки е Blowfish, кој е исто така стандарден што го користи API-то за хеширање на лозинки, бидејќи е значително попресметливо скап од MD5 или SHA1, додека сè уште е скалабилен.
На crypt() функцијата е исто така достапна за хеширање на лозинки, но се препорачува само за интероперабилност со други системи. Наместо тоа, силно се охрабрува да се користи нативниот API за хеширање на лозинки кога е можно.
-
Што е сол (salt)?
-
Криптографската сол е податок што се применува за време на процесот на хеширање за да се елиминира можноста излезот да се бара во список со претходно пресметани парови хешови и нивниот влез, познат како виножитна табела.
Попросто кажано, солта е малку дополнителни податоци што ги прави хешовите значително потешки за пробивање. Постојат голем број онлајн услуги кои обезбедуваат обемни списоци со претходно пресметани хешови, како и оригиналниот влез за тие хешови. Употребата на сол го прави неверојатно или невозможно да се најде добиениот хеш во една од овие списоци.
password_hash() ќе создаде случајна сол ако не е обезбедена, и ова е генерално најлесната и најбезбедна пристап.
-
Како се чуваат солите?
-
Кога користите password_hash() or crypt(), вратената вредност вклучува сол како дел од генерираниот хеш. Оваа вредност треба да се чува дословно во базата на податоци, бидејќи вклучува информации за користената функција за хеширање и потоа може директно да се даде на password_verify() при проверка на лозинки.
Ги ескејпува специјалните знаци во стринг за употреба во SQL изјаваpassword_verify() треба секогаш да се користи наместо повторно хеширање и споредување на резултатот со зачуван хеш за да се избегнат напади со време.
Следниот дијаграм ја покажува формата на вратената вредност од crypt() or password_hash(). Како што може да се види, тие се самостојни, со сите информации за алгоритмот и солта потребни за идна проверка на лозинката.
Белешки од корисници 3 белешки
alf dot henrik at ascdevel dot com ¶
12 години пред
swardx at gmail dot com ¶
пред 9 години
A great read..
https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
Serious Security: How to store your users’ passwords safely
In summary, here is our minimum recommendation for safe storage of your users’ passwords:
Use a strong random number generator to create a salt of 16 bytes or longer.
Feed the salt and the password into the PBKDF2 algorithm.
Use HMAC-SHA-256 as the core hash inside PBKDF2.
Perform 20,000 iterations or more. (June 2016.)
Take 32 bytes (256 bits) of output from PBKDF2 as the final password hash.
Store the iteration count, the salt and the final hash in your password database.
Increase your iteration count regularly to keep up with faster cracking tools.
Whatever you do, don’t try to knit your own password storage algorithm.
tamas at microwizard dot com ¶
пред 4 години
While I am reading the comments some old math lessons came into my mind and started thinking. Using constants in a mathematical algorythms do not change the complexity of the algorythm itself.
The reason of salting is to avoid using rainbow tables (sorry guys this is the only reason) because it speeds up (shortcuts) the "actual" processing power.
(((Longer stored hashes AND longer password increases complexity of cracking NOT adding salt ALONE.)))
PHP salting functions returns all the needed information for checking passwords, therfore this information should be treated as constant from farther point of view. It is also a target for rainbow tables (sure: for much-much larger ones).
What is the solution?
The solution is to store password hash and salt on different places.
The implementation is yours. Every two different places will be good enough.
Yes, it will make problems for hackers. He/she needs to understand your system. No speed up for password cracking will work for him/her without reimplementing your whole system.
This is my two cent.