Jak fungují hashed hesla?

[arrange]

Nějak mi není jasné, jak fungují hashed passwords na non-SSL zabezpečení. Zkusím nastínit, o co mi jde, a budu vděčný za případné vysvětlení nebo odkaz 

Příklad: fórum podobné tomuto, uživatelé. Je vůbec možné přenosy jejich hesel zabezpečit tak, aby nemohlo dojít ke kompromitaci hesel (příp. autentizace) útočníkem, který odchytí registraci uživatele? Přijde mi, že ne, protože:

• ať už je posílané heslo při registraci čisté (heslo) nebo hashed (hash(heslo)), následné přidání saltu při autentizaci je už neúčinné, protože útočník má stejné informace jako server (hash(heslo+salt), příp. hash(hash(heslo)+salt))
• pokud by se při registraci poslalo heslo již se saltem, neměl by jak server při autentizaci s jiným saltem výsledky porovnat (za předpokladu, že neukládá hesla v čisté formě, což předpokládám)

Smysl tohoto zabezpečení by byl jen tehdy, pokud by útočník znal jen komunikaci PO registraci. I tak ale v případě přihlášení a zvolení možnosti "Přihlásit: vždy" by mělo stačit odchytit údaj typu session_id.

Je to tak, nebo mi něco uniká?

[soudruh]

Pokud by jsme uložili heslo v db plaintextově, tak pak můžeme prohlížeči poslat salt ať už třeba jako cookies, nebo v nějakém js a browser pak pro autentizaci použije pouze jednou tento salt -priste samozrejme jinej (nejlepe ukldatav db jiz pouzite) + budeme paranoidni, ze session navazeme treba i na ip, browser, rozliseni, cas v pc...

[arrange]

Pokud by jsme uložili heslo v db plaintextově
To by pak nebyl žádný problém, to chápu, ale ukládání a posílání hesel clear text je všude považováno za bezpečnostní prohřešek číslo 1...

[soudruh]

Pokud by jsme uložili heslo v db plaintextově
To by pak nebyl žádný problém, to chápu, ale ukládání a posílání hesel clear text je všude považováno za bezpečnostní prohřešek číslo 1...

Pak tedy bude nejbezpecnejsi ssl, nebo jednorazovy tokeny. Pokud budeme odesilat uz z prohlizece hash hesla vzdy se stejnym saltem, tak ma tento salt stejnou dulezitost jako heslo samo.

[ETNyx]

Pěkný článek na toto téma http://php.vrana.cz/bezpecne-prihlasovani-uzivatelu.php

[arrange]

Díky za odkaz, ale odpovědi jsem se tam nedopátral, php je pro mě španělská vesnice...

Třeba co jsem zjistil (berte s rezervou): zde na fóru (SMF) se heslo při registraci pošle clear text, a pak při přihlašování jako hash hesla+challenge. Na ubuntuforums.org (vBulletin) je to podobné, jen místo clear text je to hash(heslo), a při přihlašování hash(hash(heslo)+challenge). Není mi jasné, která informace (shared secret) zde může útočníkovi chybět k man-in-the-middle attack. Sám to ale zkoušet nebudu 

[ETNyx]

V tom článku to trošku ukryté. Je tam odkaz http://php.vrana.cz/data/challenge.zip ve kterém je file reg.php

Kód: [Vybrat]

<?php
include "./lib.inc.php";

if ($_POST) {
    if (isset($_POST["password"])) {
        echo "Insecure ";
        $password_hmac_md5 = md5(hmac_md5($_POST["password"], $_SESSION["challenge"]));
    } else {
        $password_hmac_md5 = $_POST["password_hmac_md5"];
    }
    $ok = mysql_query("INSERT INTO users (login, challenge, password_hmac_md5) VALUES ('$_POST[login]', '$_SESSION[challenge]', '$password_hmac_md5')");
    echo ($ok ? "OK." : "Error.");
} else {

$_SESSION["challenge"] = get_challenge();
?>
<script type="text/javascript" src="md5.js"></script>
<script type="text/javascript">
function md5form(f) {
    f['password_hmac_md5'].value = hex_md5(hex_hmac_md5(f['password'].value, '<?php echo $_SESSION["challenge"]; ?>'));
    f['password'].disabled = true;
    f.submit();
    f['password'].disabled = false;
    return false;
}
</script>
<form action="" method="post" onsubmit="return md5form(this);">
<input type="hidden" name="password_hmac_md5" value="" />
Login: <input name="login" maxlength="20" />
Password: <input type="password" name="password" />
<input type="submit" value="Register" />
</form>
<?php } ?>
takže při registraci se odesílá odesílá md5(hmac_md5(password, challenge)). Takto by to mělo proti men.in.the.middle zabezpečené

[arrange]

Proto nabízím její vylepšení:

   1. U každého uživatele bude uložen login, challenge a md5(hmac_md5(password, challenge)).
   2. Při přihlašování se AJAXem zjistí, jaký challenge uživatel naposledy použil, a pošle se hmac_md5(password, old_challenge) a md5(hmac_md5(password, new_challenge)).

1. To už vypadá lépe, ale je to jen proof of concept. Používá se to někde? Chytilo se to? Výše uvedená fóra to např. nepoužívají.

2. Problém je shrnutý i na wikipedii

...this presents a problem for challenge-response algorithms, which require both the client and the server to have a shared secret. Since the password itself is not stored, a challenge-response algorithm will usually have to use the hash of the password as the secret instead of the password itself. In this case, an intruder can use the actual hash, rather than the password, which makes the stored hashes just as sensitive as the actual passwords.

Jinak pěkná debata na to téma i zde:
http://www.root.cz/clanky/bezpecne-prihlasovani-uzivatelu/nazory/

[MacHala]

ja myslim, ze se zabezpecovanim for, jako je tohle se nema cenu prilis zabyvat - prijdu o account? kvuli tomu se prece nerozbrecim... navic kdo by ten man in the middle attack provadel? nudici se technik od O2? a i kdyby - co by z toho mel?
za vetsi riziko nez man in the middle povazuju, ze nekdo pomoci sql injekce zmeni email spojeny s mym accountem (pochybuju, ze se bezne je sifruji) a necha si zaslat nove heslo...