Logowanie do strony www

[clu]

Witam serdecznie,
ostatnio urodził mi się w głowie pewien pomysł i zastanawiam się czy go realizować.

1. Przy tworzeniu forumularza logowania system generuje losowy hash (założyłem 32 szesnastkowe wartości - jak w MD5, zresztą nieważne)
2. Hash ten jest zapamiętywany w sesji.
3. Tworzony HTML zawiera pola PSSS (type=password), PASS (type=hidden) i oczywiście submit.
4. W <form> jest także generowany fragment JS, "wypluwający" poprzez doc.write wygenerowany wcześniej hash do zmiennej (nazwijmy ją HASZ).
5. Przy zatwierdzaniu formularza do pola PASS wstawiana jest wartość MD5(PSSS+HASZ) (łączenie stringów), a pole PASS jest czyszczone.
6. System sprawdza czy otrzymany z pola PASS hasz jest zgodny z tym, który sam sobie wygenerował i dopiero wtedy loguje użytkownika.

W teorii i przynajmniej jak dla mnie, taki sposób logowania jest bezpieczniejszy, gdyż nigdy (w teorii) nie będzie przesyłane przez sieć niezaszyfrowane hasło, a do tego za każdym razem będzie ono inne.

Zastanawiam się, czy ta teoria nie ma jakiś oczywistych dziur. Ot takie zapytanie.

[lame]

Nie ma różnicy pomiędzy tym co opisujesz, a przesyłaniem hasha hasła zamaist oryginalu.

Nie ważne jak długi string dokleisz do hasła, i tak zostanie on wygenerowany w JS, a kod JS zostanie przesłany przez HTTP, agresor bęzie miał do niego wgląd, dlatego nie poprawi to bezpieczeństwa.

uruchom logowanie przez SSL i z głowy.

[clu]

Nie ma różnicy pomiędzy tym co opisujesz, a przesyłaniem hasha hasła zamaist oryginalu.

Może masz rację, jeszcze tego nie przegryzłem do końca.. ale moim zdaniem wygląda to tak:

Jeżeli podsłucham transmisję, będę miał hash hasła to się przy jego pomocy (hasha) spokojnie zaloguję. A w moim przypadku serwer za każdym razem czeka na inny hash. Nawet jeżeli zdobędę hash z któregoś logowania, to będzie on przy kolejnym logowaniu bezużyteczny, czy nie?

Temat SSL pomijam celowo, chyba bardziej myślę o tym rozwiązaniu jako dodatkowym "dla sportu"

[lame]

W moim przypadku serwer za każdym razem czeka na inny hash. Nawet jeżeli zdobędę hash z któregoś logowania, to będzie on przy kolejnym logowaniu bezużyteczny, czy nie?

Nie, agresor i tak bedzie wiedzial jaki to hash, bo podslucha transmisje podczas ktorej hash ten zostanie przekazany do skryptu javascript.

Postaw SSL, to nic nie kosztuje..

//edit
Da rade inaczej...

Można by użyć bibliteki implementującej algorytm szyfrowania AES pod javascript
link: JavaScript Implementation of AES Advanced Encryption Standard in Counter Mode

1. szyfrujesz przy pomocy wpisanego hasla np. swój numer sesji
2. przesyłasz zaszyfrowany ciag znakow do serwera.
3. serwer sprawdza czy przeslany ciag znakow jest zaszyfrowanym numerem sesji usera i loguje.

[clu]

Kurcze, albo za mało kawy dzisiaj wypiłem i dlatego nie kumam albo nie umiem tłumaczyć. Zapytam inaczej.

Jeżeli agresor podsłucha hash wygenerowany przez serwer a potem zahashowane hasło przy pomocy tegoż hasha, to jak je wykorzysta do zalogowania skoro przy każdym kolejnym podejściu serwer będzie oczekiwał hasła zahashowanego przy pomocy innego hasha?

Sorry, że takie długie zdanie.

BTW dzięki za linka do AES
BTW2 SSL spoko, też jest

[lame]

(...) to jak je wykorzysta do zalogowania skoro przy każdym kolejnym podejściu serwer będzie oczekiwał hasła zahashowanego przy pomocy innego hasha?

Ponieważ agresor, tak samo jak przeglądarka uzytkownika, bedzie znal ten hash.

[TQM]

Jesli rozumiem to chodzi Ci o takie cos jak MD5 z salt'em, czyli serwer podaje do przegladarki salt, klient podaje haslo, JS dokleja haslo do salt'u i hashuje string ktory uzyskal, odsyla do serwera, serwer sprawdza...

Jak dla mnie sa z tym 2 problemy:
1. serwer musi miec haslo usera zapisane plaintext aby mogl je zlozyc z salt'em i zahashowac aby miec co porownac... a kazdy Ci powie ze miec hasla w plaintext to zly pomysl
2. zakladajac ze atakujacy uslyszy salt ktory wyslal serwer i uslyszy odpowiedz... bedzie mogl zrobic atak slownikowy albo brute-force aby poznac haslo usera...

Owszem, utrudni to zadanie atakujacemu ale poza tym nie wiele daje moim zdaniem, glownie dlatego ze musisz miec hasla w bazie jakiejs w postaci jawnej i to dla mnie dyskwalifikuje taki system. Sorry...

[clu]

O, chyba zostałem zrozumiany. Słowo klucz dla clu na dzisiaj - "salt"

ad1. Nie przyszłoby mi do głowy trzymać jakichkolwiek haseł plainem. Pominąłem tu nieistoty fakt dla samego głównego zagadnienia. Oczywiście sytuacja wygląda tak, że na serwerze jest MD5(PASS), a przy szyfrowaniu przy pomocy JS szyfrujemy MD5( MD5(PASS) + HASH). To załatwia sprawę, ale uwaga słuszna.

ad2. atak słownikowy można zrobić zawsze (więc co ani bardziej ani mniej chyba?), ale tutaj za każdym razem serwer oczekuje innego hasha, więc jest nawet szansa, że atakujący przeleci przez wszystkie możliwe kombinacje MD5 i nie wejdzie (z drugiej strony, odpowiednio długo strzelając tym samym MD5, też dałoby się zalogować - ale jaki problem zablokować IP na kilkanaście minut po każdych kilku próbach?)

Pytanie nadal brzmi, czy znajomość salt1 i HASZła w połączeniu z znajomością salt2 coś daje?

Czy znajomość wielu saltów i wielu HASZeł daje coś więcej?

[lame]

Teraz to ja nie rozumiem.

Skąd JavaScript będzie wiedział jaki ma być salt
oraz skąd serwer będzie wiedział jaki ma być salt?

Uruchomią miedzy sobą jakiś asymetryczny szyfrowany kanał komunikacyjny?

[lame]

Ok, zrobiłem PoC logowania, gdzie hasło jest napierw szyfrowane algorytmem AES-256 po strone przeglądarki,
nastepnie w postaci zaszyfrowanej wysyłane na serwer i tam walidowane.

Po stronie klienta:

<html>
<head>
<script src="aes.js"></script>
<script src="sha1.js"></script>
</head>
<body>

<form id="mysubmit" action="login.php" method="POST">
<input type="password" name="pass"/>
<input type="hidden" name="sess" value="bd307a3ec329e10a2cff8fb87480823da114f8f4"/>
<input type="submit" value="zaloguj"/>
</form>
<script>

document.getElementById('mysubmit').onsubmit = function() {
	
	var pass = this.pass
	var sess = this.sess
	
	var encr = AesCtr.encrypt(sess.value, sha1(pass.value), 256)
	
	pass.value = encr
	
}

</script>
</body>
</html>

źródła:
aes.js: JavaScript Implementation of AES Advanced Encryption Standard in Counter Mode
sha1.js : JavaScript sha1 - php.js
utf-encode.js : JavaScript utf8_encode - php.js



Po stronie serwera:

<?php

include 'aes.php';

if ( $_POST['sess'] == AESDecryptCtr($_POST['pass'], sha1('haslo'), 256)) {
    die('ok');
}
else {
    die('error');
}

?>

źródła:
aes.php : PHP Implementation of AES Advanced Encryption Standard in Counter Mode

It Works!
O ile ta implementacja AES nie ma backdoora