[html] Password hashen (unobtrusive) zonder SSL

[iH8]

Ik heb dus een password input welke momenteel via JS client-side gehashed wordt zodat het niet als plain-text de lijn over gestuurd wordt. Nu hoor ik van iedereen, vooral in ajax topics dat unobtrusiveness een must is. Zou ik voor mensen zonder JS gewoon plain-text moeten verzenden? Niet echt veilig vind ik. Zijn er dan nog andere opties buiten SSL? Of gooi je in dit geval gewoon dat unob. overboord en verplicht je mensen tot het aanhebben staan van JS? Hoe fixen jullie dat en hebben jullie het uberhaubt wel gefixed? Ik kom na wat onderzoek bar veel websites tegen die zonder ssl gewoon plain-text versturen. Wat denken jullie?

[Blaise]

Waarschuwing in de HTML voor bezoekers zonder JS, wel toestaan om plaintext te versturen.

Hangt ook af van het type website natuurlijk; of er gevoelige/financiële data van gebruikers wordt opgeslagen.

[ Voor 16% gewijzigd door Blaise op 19-11-2008 19:46 ]

[Zakkenwasser]

met php doen en in een database opslaan als sha1

zie ook:
http://nl3.php.net/sha1

op die manier lijkt me toch wat veiliger, en gebruiksvriendenlijker ook voor de bezoekers zonder javascript enabled

[ Voor 8% gewijzigd door Zakkenwasser op 19-11-2008 22:10 ]

[ibmos2warp]

iH8 schreef op woensdag 19 november 2008 @ 19:25:
Ik heb dus een password input welke momenteel via JS client-side gehashed wordt zodat het niet als plain-text de lijn over gestuurd wordt.

Houd je er wel rekening mee dat je dus die javascript en andere zooi ook over de lijn gooit? Dus als je dat hebt + het gehasdepassword dan is het vast wel mogelijk om dat password weer te krijgen.
En weet je het zeker dat je het hashed en niet encrypt?

MrJey schreef op woensdag 19 november 2008 @ 21:43:
met php doen en in een database opslaan als md5
(...)
op die manier lijkt me toch wat veiliger, en gebruiksvriendenlijker ook voor de bezoekers zonder javascript enabled

Dan stuur je het dus als plain-text over de lijn. Ik denk dat de TS'er geëncrypted bedoelt, zoals RSA. Als hij er bij de client al bijvoorbeeld een md5 hash van maakt dan is dat in princiepe gewoon hetzelfde als een password.

[Zakkenwasser]

ibmos2warp schreef op woensdag 19 november 2008 @ 21:57:

Dan stuur je het dus als plain-text over de lijn. Ik denk dat de TS'er geëncrypted bedoelt, zoals RSA. Als hij er bij de client al bijvoorbeeld een md5 hash van maakt dan is dat in princiepe gewoon hetzelfde als een password.

[code=php]
$username = trim(mysql_prep($_POST['username']));
$password = trim(mysql_prep($_POST['password']));
$hashed_password = sha1($password);

if ( empty($errors) ) {
$query = "INSERT INTO users (
username, hashed_password
) VALUES (
'{$username}', '{$hashed_password}'
)";
$result = mysql_query($query, $connection);
if ($result) {
$message = "The user was successfully created.";
} else {
$message = "The user could not be created.";
$message .= "<br />" . mysql_error();
}

[/code=php]
Neen, meer zoiets.

[Verwijderd]

MrJey schreef op woensdag 19 november 2008 @ 22:08:

Neen, meer zoiets.

Zeg sherlock, hoe krijg je het wachtwoord op de server zonder het plaintext in een HTTP request mee te sturen?

[Zakkenwasser]

Verwijderd schreef op woensdag 19 november 2008 @ 22:10:
[...]

Zeg sherlock, hoe krijg je het wachtwoord op de server zonder het plaintext in een HTTP request mee te sturen?

uhm, met een loop?

[Zeebonk]

@MrJey: Cheetah bedoeld dat een form post aankomt op de server, het gaat hier over die verbinding, waarin je form data plain text wordt verstuurd. Wat jij doet is na het ontvangen op de php server een hash er overheen gooien.

edit:
Zelf wel erg benieuwd wat hier WEL een goede oplossing voor zou zijn... Wel wat over ssl gelezen, maar is dat de eenige oplossing?

[ Voor 23% gewijzigd door Zeebonk op 19-11-2008 22:16 ]

[Morrar]

Verwijderd schreef op woensdag 19 november 2008 @ 22:10:
[...]

Zeg sherlock, hoe krijg je het wachtwoord op de server zonder het plaintext in een HTTP request mee te sturen?

Lijkt me dus inderdaad dat je alleen SSL en Javascript als opties overhoudt. MD5 implementaties in Javascript zijn overigens met Google goed te vinden: http://www.google.nl/sear...official&client=firefox-a

Of je plaintext daarnaast ook wilt toestaan hangt nogal af van hoe veilig het moet zijn. Afhankelijk van je opzet, kan een gehackte account door plaintext versturen al een hoop verstieren. En Javascript lijkt me nou ook weer niet zo'n hoge drempel.

[Verwijderd]

Morrar schreef op woensdag 19 november 2008 @ 22:18:

Lijkt me dus inderdaad dat je alleen SSL en Javascript als opties overhoudt.

En HTTP Digest authentication, maar dat kan alleen werken zoals je wilt, als het wachtwoord al op de server bekend is.

MD5 implementaties in Javascript zijn overigens met Google goed te vinden: http://www.google.nl/sear...official&client=firefox-a

Of je plaintext daarnaast ook wilt toestaan hangt nogal af van hoe veilig het moet zijn. Afhankelijk van je opzet, kan een gehackte account door plaintext versturen al een hoop verstieren. En Javascript lijkt me nou ook weer niet zo'n hoge drempel.

Precies, het ligt aan het exacte doel. Optioneel wil je de gebruiker de mogelijkheid bieden gewoon plaintext te authenticeren. Als het heel belangrijk is dat dit niet kan, is een budget voor een SSL certificaat vaak ook niet zo'n probleem. En anders kun je altijd een self-signed certificaat gebruiken. Again: dit is afhankelijk van doel en doelgroep.

[iH8]

ik maak via js clientside een hash van een door de server genereerde random string en het wachtwoord en die verstuur ik. bij ontvangen maakt de server diezelfde hash van het opgeslagen wachtwoord en de random string. dan vergelijk ik de clienthash met de serverhash. challenge / response. ik moet dus al hashen kunnen op clientside maar HTML heeft daar geen functionaliteit voor zover ik weet dus ik kom automatisch bij JS terecht.

[RobIII]

iH8 schreef op woensdag 19 november 2008 @ 22:35:
bij ontvangen maakt de server diezelfde hash van het opgeslagen wachtwoord en de random string

Dus je slaat het wachtwoord plain text op in je DB (of ergens anders)? In dat geval zou ik daar eerst eens aandacht aan besteden i.p.v. het wiel vierkant uit te vinden.

[iH8]

ok ok, ik had het uitleg technisch maar wat simpel gehouden. ik maak een sha van het password, dan een sha van die sha + string. die verstuur ik. die vergelijk ik met een sha van het wachtwoord (staat gesha'ed in de DB) + string.

[Cartman!]

Ik gebruik soms de methode:

Inloggen naar client: salt en een random string
clientside: hash(hash(salt+wachtwoord)+random string)
serverside: hash(wachtwoord uit db+random string)

Het wachtwoord in de db is dus ook gesalt.

Registreren naar client: salt
clientside: hash(salt+wachtwoord)
server: opslaan in db

Zo gaat nooit je wachtwoord plain over de lijn, ook niet tijdens registratie. En bij het inloggen heb je altijd een wisselende hash die maar 1 keer geldig is. Uiteraard detecteer je of iemand wel javascript aan heeft en zoniet, dan werkt het zonder clientside hashing ook.