[PHP] safelogin

[Verwijderd]

Ik ben bezig met mijn site, en ik zat te denken, hoe kan ik voor mijn site de maximale veiligheid benaderen, dit zonder gebruik te maken van https?
Het enige dat niet mag afgetapt mag worden is registreren (dat wordt moeilijk) en inloggen.
Voor inloggen had ik al een keer iets bedacht alleen vergeten, weet het weer:

code:

passwordcode->user
sha(sha(password)+passwordcode)->server
if sha(sha(password)+passwordcode) = sha(shapassword+passwordcode)
then login()

dit is compleet veilig lijkt me, omdat ze de passwordcode kunnen aftappen, maar als dit verwerkt is in een sha kunnen ze alleen password weten als ze kunnen terugreken en dan is sha toch nutteloos en vervang ik hem.
sha(password) moet eerst gedaan worden omdat hij safe in de database moet staan.
passwordcode is dan een randomcode die bij het opvragen van de site gebonden wordt aan jouw ip. Elke keer als je de inlog pagina opnieuw opent doet hij dit dus.

register lijkt me dan op zo'n zelfde manier
maar dan moet inloggen ook veranderen en 2 passwordscodes gebruiken, wat dus sha(password+passwordcode). Inloggen zal dan moeten gaan werken met AJAX of hoe je het ook maar noemt (ik doe het meestal met frames ofzo). Dus dan krijg je dit bij het inloggen:

code:

passwordcode->user
password en username ingevuld en om submit geklikt.
username->server
passwordcode2->user
passwordcode3->user
sha(sha(sha(password+passwordcode2)+passwordcode3)+passwordcode)->server
if sha(sha(sha(password+passwordcode2)+passwordcode3)+passwordcode) = sha(shapassword+passwordcode)
then login()

en bij registreren:

code:

passwordcode->user
sha(password+passwordcode2)->server
passwordcode->server
sha(password+passwordcode3)+passwordcode2+passwordcode3->mysqlquery
mysql query

Is dit veilig en is het mogelijk om dit te kunnen acceleren? Kan me namelijk indenken dat zoveel sha's een grote druk leggen op client(3sha's) en voor de server (1sha inloggen en 1 sha bij registeren)
Iemand misschien tips, hoe het sneller of efficiënter kan?

[ Voor 0% gewijzigd door Verwijderd op 27-01-2008 20:07 . Reden: wat haakjes en codes vergeten... ]

[Muthas]

Een sha1 is niet erg CPU-intensief, één per inloggen boeit niet

Ik weet niet precies wat jij allemaal doet, maar als je eens zoekt naar 'salt' en een javascriptje om clientside te sha1 te doen dan ben je zo klaar.

[Megamind]

Ik heb zelfs gewoon de username ge MD5't.

Je kan dit in MySQL doen:

SELECT * FROM users WHERE username = md5($username)

En boeiend als het een halve seconde later duurt, het is wel het veiligst.

[Verwijderd]

Dat doe ik liever niet omdat ik vind dat je niet makkelijk in je tabel kan kijken om dingen aan te passen. Ook kan je niet zeggen: goedemorgen Piet!, geeft een beetje weinig meerwaarde om je username in md5 te gooien vind ik. Daarnaast gebruik ik zowiezo md5 niet omdat het in 3 kwartier te kraken is door een pentium 4 1,8ghz (!)

[ Voor 18% gewijzigd door Verwijderd op 27-01-2008 22:06 ]

[Megamind]

2 dingen.

MD5 kraken? Nou nee. Misschien opzoeken met een lijst.

En ik schrijf WHERE username = md5($username), waar $username = "Piet" is. Hij wordt IN mysql in MD5 gezet, en dan pas vergeleken. Je kan dan gewoon alle usernames plain opslaan.

[Snake]

MD5 is niet te kraken, er kan alleen een andere string worden opgezocht via zogenaamde 'Rainbow-tables', die dezelfde hashes heeft

Dus de access tot u database moet ge heel goed beveiligd in eerste instantie

[ID-College]

idd, md5 is niet te kraken.
Wat ik doe, haal je password via sql eruit en username. Wat ik deed om een ww op te slaan was altijd:

PHP:

$var1 = "^&*(#@$HKJ"; //zoiets
$var2 = "HJK#$&(*)FHDJ"; //nog wat rare tekens

$pass = sha(md5($var1.$password.$var2));

Nu kan ik me ww nooit niet terugvinden, en iemand kan het sowieso niet makkelijk vinden.
Als je zoiets toepast op een ww is het niet 1,2,3 terug te halen.
Misschien beetje overkill maja, het werkt. Boeie

[Superdeboer]

Kijk eens in dit topic, daar staat wel een fatsoenlijke discussie over de dingen die belangrijk zijn bij een loginscript (en eventueel daarbij behorend sessiebeheersysteem): [PHP] BeveiligingsTips nodig

[Megamind]

ID-College schreef op zondag 27 januari 2008 @ 22:20:
idd, md5 is niet te kraken.
Wat ik doe, haal je password via sql eruit en username. Wat ik deed om een ww op te slaan was altijd:

PHP:

$var1 = "^&*(#@$HKJ"; //zoiets
$var2 = "HJK#$&(*)FHDJ"; //nog wat rare tekens

$pass = sha(md5($var1.$password.$var2));

Nu kan ik me ww nooit niet terugvinden, en iemand kan het sowieso niet makkelijk vinden.
Als je zoiets toepast op een ww is het niet 1,2,3 terug te halen.
Misschien beetje overkill maja, het werkt. Boeie

Dan nog als je gaat inloggen, gaat je username plain over de lijn (tenzij je SSL hebt).

Zowiezo kan SHA omgedraaid worden, en als je een vaste key hebt dan wordt het weer iets makkelijker.

Het beste is bij elke registratie een user een SALT te geven (een paar random tekens), die je mee md5't.

[Toolskyn]

Misschien ook eens interessant om naar deze pagina te kijken van de maker van een stukje sha1/md5 code voor javascript.

[ID-College]

Megamind schreef op zondag 27 januari 2008 @ 22:23:
[...]

Dan nog als je gaat inloggen, gaat je username plain over de lijn (tenzij je SSL hebt).

Zowiezo kan SHA omgedraaid worden, en als je een vaste key hebt dan wordt het weer iets makkelijker.

Het beste is bij elke registratie een user een SALT te geven (een paar random tekens), die je mee md5't.

Klopt, maar hoever wil je gaan. Ik weet niet waar de TS het voor gebruikt, maar voor mij is het gewoon hobby/school dus zeker niet nodig om zwaar te beveiligen. Er zitten mede ICTers in de klas en die weten er ook het eea vanaf, maar dit volstaat zeker voor regulier gebruik

[Cartman!]

Zowel inloggen als registeren kun je voor elkaar krijgen zonder dat het password plain over de lijn gaat.

Registeren:
server salt naar je client sturen, user toetst password in en voor verzenden hash je dit (bijv. sha1 of een nieuwe algoritme) en sla je dit op in de database (hash(password+salt).

Inloggen:
pagina met username+password velden en een 2 hidden fields met daarin de server salt + een random code die je serverside in je session bewaart. voor verzenden hash je: hash(randomcode +hash(password+salt)). Serverside kun je de login controleren door de randomcode uit je session te hashen met je database entry voor die user. Zo stuurt de user altijd een unieke random code over de lijn waar zn wachtwoord in zit die slechts geldig is in die sessie.

edit:
per user een aparte salt kan, maar dan zul je de login moeten verdelen in stappen omdat je clientside anders de user salt nog niet hebt.

[ Voor 8% gewijzigd door Cartman! op 27-01-2008 23:52 ]

[djiwie]

Megamind schreef op zondag 27 januari 2008 @ 22:23:
Zowiezo kan SHA omgedraaid worden, en als je een vaste key hebt dan wordt het weer iets makkelijker.

Dat lijkt me sterk, het is een hash-functie. Wellicht bedoel je opzoeken in rainbow tables?

[Verwijderd]

Als je goed leest gebruik ook random codes, ik gebruik er hier zelfs 3, 2 bij registartie en 1 bij login, ga hem dan zo snel mogelijk inbouwen
@cartman, dat had ik hier al gedaan
Weet iemand waar ik javascript 512 ofzo vandaan haal, kan er alleen 1 vinden voor internet explorer en dat moeten we natuurlijk niet hebben

[ Voor 28% gewijzigd door Verwijderd op 28-01-2008 07:16 ]

[Alm4riC]

Een tijdje geleden een hele aardige tutorial tegen gekomen op een ander forum

http://ep2.nl/topic/4026/

hier een linkje

[voodooless]

Natuurlijk kun je ook nog wat form data encrypten als je dat zou willen Er is een AES lib voor javascript beschikbaar welke prima werkt. Als key kun je de bijvoorbeeld MD5 nemen van het wachtwoord (eventueel met challenge en/of salt erbij).

- SHA javascript spul kun je hier vinden: http://anmar.eu.org/projects/jssha2/
- MD5 javascript spul kun je hier vinden: http://pajhome.org.uk/crypt/md5/md5src.html

Er zijn ook nog wel andere implementaties te vinden met een beetje zoeken

[BCC]

Cartman! schreef op zondag 27 januari 2008 @ 23:51:
Zowel inloggen als registeren kun je voor elkaar krijgen zonder dat het password plain over de lijn gaat.

Alles via https laten verlopen is natuurlijk ook een eenvoudige, maar krachtige oplossing hiervoor.

Er wordt hierboven heel vaak combinaties van SHA en MD5 of meerdere MD5 slagen van iets gemaakt. Let er even op dat dit in sommige gevallen de beveiliging zal doen afnemen.

[Verwijderd]

Megamind schreef op zondag 27 januari 2008 @ 22:11:
En ik schrijf WHERE username = md5($username), waar $username = "Piet" is. Hij wordt IN mysql in MD5 gezet, en dan pas vergeleken. Je kan dan gewoon alle usernames plain opslaan.

Wat is het punt van md5 dan nog?

[Verwijderd]

bedankt voodooless, daar kan ik wel goed mij uit de voeten denk ik.

Alles via https laten verlopen is natuurlijk ook een eenvoudige, maar krachtige oplossing hiervoor.

dit zonder gebruik te maken van https?

heb namelijk geen https op mijn server, of in ieder geval geen certificaat.(xxamp)

[Megamind]

Verwijderd schreef op maandag 28 januari 2008 @ 10:42:
[...]
Wat is het punt van md5 dan nog?

Dat niets plaintext over de lijn gaat.

[Patriot]

Javascript 512? Wat bedoel je daar mee?

EDIT: Goeedd... dat krijg je er dus van als je in topics gaat reageren die je al sinds vanochtend open hebt staan

[ Voor 61% gewijzigd door Patriot op 28-01-2008 13:53 . Reden: foutje, bedankt ]

[Verwijderd]

Ja, 7:13 was ook voor mij vroeg, bedoelde sha-512. Maar ik ga die maar niet gebruiken aangezien ik niet eens een php512 kan vinden. Dan maar sha-256. Dat was in het opzichte van:
- veiligheid
-

Er wordt hierboven heel vaak combinaties van SHA en MD5 of meerdere MD5 slagen van iets gemaakt. Let er even op dat dit in sommige gevallen de beveiliging zal doen afnemen.

Bij een grotere hash lijkt het mij aannemelijk dat de beveiligheid en daarmee aantal codes per hash afneemt. (bij kleine hashes heb je nog wel eens meerdere invoer codes voor dezelfde hash.

[Cartman!]

SHA512 zit vrijwel altijd in PHP5 inbegrepen in de hash() functie en anders eventueel in de mhash() extension die servers wel eens hebben.

[Verwijderd]

Megamind schreef op maandag 28 januari 2008 @ 13:17:
Dat niets plaintext over de lijn gaat.

Ja maar of het nu plain text of gehasht over de lijn gaat maakt helemaal niets uit. Het is gewoon een call met username en password. Het idee van de hash opslaan in je database is dat je het originele juist niet weet.

[Woy]

Verwijderd schreef op maandag 28 januari 2008 @ 14:05:
Ja, 7:13 was ook voor mij vroeg, bedoelde sha-512. Maar ik ga die maar niet gebruiken aangezien ik niet eens een php512 kan vinden. Dan maar sha-256. Dat was in het opzichte van:
- veiligheid
-
[...]

Bij een grotere hash lijkt het mij aannemelijk dat de beveiligheid en daarmee aantal codes per hash afneemt. (bij kleine hashes heb je nog wel eens meerdere invoer codes voor dezelfde hash.

Hij bedoeld te zeggen dat md5( md5( $password ) ) niet veiliger is als md5( $password )

[Cartman!]

Verwijderd schreef op maandag 28 januari 2008 @ 14:22:
[...]
Ja maar of het nu plain text of gehasht over de lijn gaat maakt helemaal niets uit. Het is gewoon een call met username en password. Het idee van de hash opslaan in je database is dat je het originele juist niet weet.

Dat laatste klopt maar het nadeel van je wachtwoord plain over de lijn sturen is dat iemand met een package sniffer je wachtwoord gewoon voorbij ziet komen, aan de hash kan diegene je wachtwoord niet meer zien. Echter door puur op die manier te valideren zal iemand gewoon dezelfde post kunnen nadoen (replay) en zou die ingelogd zijn. Door een random waarde mee te hashen in wat over de lijn gaat kun je dit teniet doen, die code is namelijk alleen geldig in de sessie van die persoon.

[Megamind]

Cartman! schreef op maandag 28 januari 2008 @ 15:48:
[...]

Dat laatste klopt maar het nadeel van je wachtwoord plain over de lijn sturen is dat iemand met een package sniffer je wachtwoord gewoon voorbij ziet komen, aan de hash kan diegene je wachtwoord niet meer zien. Echter door puur op die manier te valideren zal iemand gewoon dezelfde post kunnen nadoen (replay) en zou die ingelogd zijn. Door een random waarde mee te hashen in wat over de lijn gaat kun je dit teniet doen, die code is namelijk alleen geldig in de sessie van die persoon.

Hm daar heb je gelijk in, daar had ik nog niet aan gedacht.

[Verwijderd]

Ok, cartman bedankt, kon namelijk hem niet in de documentatie vinden, wel 256 bits. Edit: gevonden: http://a0002.blogspot.com...mplementation-of-sha.html edit: werkt niet, is nog niet af blijkbaar, maar wel verkondigen dat hij het doet

Dat laatste klopt maar het nadeel van je wachtwoord plain over de lijn sturen is dat iemand met een package sniffer je wachtwoord gewoon voorbij ziet komen, aan de hash kan diegene je wachtwoord niet meer zien. Echter door puur op die manier te valideren zal iemand gewoon dezelfde post kunnen nadoen (replay) en zou die ingelogd zijn. Door een random waarde mee te hashen in wat over de lijn gaat kun je dit teniet doen, die code is namelijk alleen geldig in de sessie van die persoon.

Daar was mijn beveiliging dus voor bedoeld, je legt het beter uit:P

[ Voor 11% gewijzigd door Verwijderd op 28-01-2008 19:08 ]

[Sh4wn]

IMO is het beste login systeem een systeem waar je een eigen sessie systeem maakt.

je hebt bijv. een tabel users met userdata etc. en een tabel sessions met alle sessies. Structuur van het sessie tabel:

session_id VARCHAR(32)
user_id INT(11)
session_last_update UNSIGNED INT(11)
session_length UNSIGNED INT(11)
session_logged_in TINYINT(1)
session_ip VARCHAR(15)

Als er een bezoeker op je site komt, kijk je of er een cookie bestaat genaamd 'sid' of hoe je het ook wil noemen. Hierin staat het sessie_id, die overeen komt met een sessie in het tabel. Het sessie_id is gewoon een md5 hash van een random getal/waarde.

Het tabel sessies heeft ook een veld session_length, hier in staat opgeslagen hoelang de sessie duurt. Bij elke request verwijder je eerst alle verlopen sessies, door session_last_update en session_length te vergelijken met de huidige tijd.

Na die check lees je de cookie value uit met het session_id (check ook voor geldige karakters e.d.), check of de user bestaat, het IP klopt etc.

Daarna update je session_last_update naar de huidige timestamp.

Op deze manier kan je toch een soort van 'auto login' hebben op je site, zonder dat je het password van de user in een cookie opslaat oid. Ook kan je een soort van sessie beheer maken zoals hier op tweakers.



Mijn wachtwoorden heb ik trouwens gehashed met SHA256 (en ja PHP heeft support voor dat, zie de hash functie

[mithras]

Sh4wn schreef op maandag 28 januari 2008 @ 22:16:
IMO is het beste login systeem een systeem waar je een eigen sessie systeem maakt.

Het lijkt erg op crisp in "[PHP] BeveiligingsTips nodig", maar toch met een paar nadelen.

je hebt bijv. een tabel users met userdata etc. en een tabel sessions met alle sessies. Structuur van het sessie tabel:

session_id VARCHAR(32)
user_id INT(11)
session_last_update UNSIGNED INT(11)
session_length UNSIGNED INT(11)
session_logged_in TINYINT(1)
session_ip VARCHAR(15)

Als er een bezoeker op je site komt, kijk je of er een cookie bestaat genaamd 'sid' of hoe je het ook wil noemen. Hierin staat het sessie_id, die overeen komt met een sessie in het tabel. Het sessie_id is gewoon een md5 hash van een random getal/waarde.

Php kent gewoon session_id()

Het tabel sessies heeft ook een veld session_length, hier in staat opgeslagen hoelang de sessie duurt. Bij elke request verwijder je eerst alle verlopen sessies, door session_last_update en session_length te vergelijken met de huidige tijd.

Waarom werk je met dubbele fields voor een ttl, waar je ook in de plaats een veld met een ttd timestamp kan plaatsen

Na die check lees je de cookie value uit met het session_id (check ook voor geldige karakters e.d.)

Als je gewoon een lookup in de database doet met een nette escape, kan er geen fout optreden. De extra "ongeldige" karakters maakt het nodeloos ingewikkeld

check of de user bestaat, het IP klopt etc.

Een lock aan ip is niet voor iedereen wenselijk, alleen in bepaalde gevallen als een user er specifiek voor kiest. Denk aan de gevallen dat iemand een dynamisch ip heeft of wanneer een user in een bedrijfsomgeving inlogt, waar alle werknemers naar buiten toe eenzelfde ip hebben

Daarna update je session_last_update naar de huidige timestamp.

Als je een update doet op je sessie tabel en een veld timestamp hebt (ipv datetime) wordt het veld automagisch geupdate

Op deze manier kan je toch een soort van 'auto login' hebben op je site, zonder dat je het password van de user in een cookie opslaat oid. Ook kan je een soort van sessie beheer maken zoals hier op tweakers.

In principe gaat het sessiebeheer van TS wel ok, maar ging het vooral om CRAM.

[Verwijderd]

Sh4wn schreef op maandag 28 januari 2008 @ 22:16:
IMO is het beste login systeem een systeem waar je een eigen sessie systeem maakt.

[...]

Dat zou ik niet doen. PHP kent een uitgebreid en goed getest sessie-systeem.

De kans dat je zelf een sessie-systeem bouwt dat veiliger is dan dat van PHP zelf, is nihil. Er zijn zoveel subtiliteiten waar je rekening mee moet houden, en een ongeluk zit in een klein hoekje.

Allerlei commerciële bedrijven schrijven hun eigen, proprietary encryptie-algoritmen. Zij maken daarbij, een enkele uitzondering daargelaten, allemaal dezelfde beginnersfouten.

Maak gebruik van standaard componenten die zichzelf bewezen hebben. Deze componenten zijn uitgebreid getest en uitontwikkeld.

[Voutloos]

Verwijderd schreef op dinsdag 29 januari 2008 @ 00:31:
De kans dat je zelf een sessie-systeem bouwt dat veiliger is dan dat van PHP zelf, is nihil. Er zijn zoveel subtiliteiten waar je rekening mee moet houden, en een ongeluk zit in een klein hoekje.

Uiteraard moet je niet klakkeloos altijd het wiel opnieuw uitvinden, maar je eigen session handler kan leuke voordelen bieden tov de normale sessies, wat het wel de moeite waard maakt. Verder is je eigen sessie systeem schrijven ook weer geen rocket science.

Allerlei commerciële bedrijven schrijven hun eigen, proprietary encryptie-algoritmen. Zij maken daarbij, een enkele uitzondering daargelaten, allemaal dezelfde beginnersfouten.

De fout die met name gemaakt wordt is dat er al encryptiemethoden zijn welke onder het kopje proven security vallen (RSA), maar dat iedere beunhaas denkt dat strings reversen met rot13 er overheen compleet onraadbaar is.

Voor encryptie en hashing zijn idd goede algoritmes voor handen en is er eigenlijk niet zomaar een excuus te bedenken om zelf iets te implementeren.

[Sh4wn]

Verwijderd schreef op dinsdag 29 januari 2008 @ 00:31:
[...]


Dat zou ik niet doen. PHP kent een uitgebreid en goed getest sessie-systeem.

De kans dat je zelf een sessie-systeem bouwt dat veiliger is dan dat van PHP zelf, is nihil. Er zijn zoveel subtiliteiten waar je rekening mee moet houden, en een ongeluk zit in een klein hoekje.

Allerlei commerciële bedrijven schrijven hun eigen, proprietary encryptie-algoritmen. Zij maken daarbij, een enkele uitzondering daargelaten, allemaal dezelfde beginnersfouten.

Maak gebruik van standaard componenten die zichzelf bewezen hebben. Deze componenten zijn uitgebreid getest en uitontwikkeld.

Nadeel van PHP's sessie systeem is dat je de lengte van de sessie nief kan bepalen, en elke keer opnieuw moet inloggen.

[Cartman!]

Het sessie systeem wat je gebruikt staat los van de manier van inloggen dus ik snap de hele ophef hierover niet. Je sessie maak je pas aan als iemand veilig is ingelogd. Zelf heb ik een soortgelijk systeem gemaakt wat vrijwel identiek werkt als het systeem hier op GoT en daar zitten zeker voordelen aan omdat je nu alles zelf in de hand hebt en welke gegevens je allemaal opslaat.

[Muthas]

Sh4wn schreef op dinsdag 29 januari 2008 @ 19:19:
[...]


Nadeel van PHP's sessie systeem is dat je de lengte van de sessie nief kan bepalen, en elke keer opnieuw moet inloggen.

Moet je voor de grap is php.ini bekijken Verder kan je natuurlijk wel zelf een cookie laten setten waarmee je automatisch laat inloggen, daarvoor hoef je het php sessie systeem niet te vervangen.

Overigens werk ik ook liever met mijn eigen sessiesysteem. Kan je handige dingen mee doen zoals ingelogde gebruikers tellen, meerdere sessies per gebruiker etc.

[Fugitive1977]

verkeerde forum

[ Voor 90% gewijzigd door Fugitive1977 op 30-01-2008 16:52 ]

[Verwijderd]

Muthas schreef op dinsdag 29 januari 2008 @ 19:43:
[...]
Overigens werk ik ook liever met mijn eigen sessiesysteem. Kan je handige dingen mee doen zoals ingelogde gebruikers tellen, meerdere sessies per gebruiker etc.

Eigen sessies afhandeling zijn inderdaad erg handig. Je kan er meer controle over uitvoeren waardoor het ook vaak beter te beveiligen is. Zo kan je ook je sessies in een database bijhouden. Bij een drukke website moet je hier natuurlijk wel mee uitkijken, maar het is wel heel erg handig.

Zie die php functie: session_set_save_handler();

http://nl2.php.net/manual...sion-set-save-handler.php

[Verwijderd]

Megamind schreef op zondag 27 januari 2008 @ 22:11:
En ik schrijf WHERE username = md5($username), waar $username = "Piet" is. Hij wordt IN mysql in MD5 gezet, en dan pas vergeleken. Je kan dan gewoon alle usernames plain opslaan.

Dit heeft volgens mij weinig effect, behalve dat je de usernames niet als plain text in de db opslaat. De username komt nog steeds als plain text over de lijn...


Persoonlijk zou ik het password op de client in js hashen en dan over de lijn gooien. In je db sla je dan alleen de hashes op. Dit zorgt ervoor dat het password niet ff uitgelezen kan worden dmv packet sniffing of als men toegang heeft tot de db.
Je kan eventueel gewoon alle data encrypten op basis van bijv session id, dit blijft overigens altijd een lastig punt. Er wordt altijd een plain text key (dus in het voorbeeld je session id) over de lijn gestuurd, welke dus gesniffed kan worden...

[BCC]

Verwijderd schreef op donderdag 31 januari 2008 @ 14:17:
[...]
Er wordt altijd een plain text key (dus in het voorbeeld je session id) over de lijn gestuurd, welke dus gesniffed kan worden...

Je bent nu het wiel opnieuw aan het uitvinden. Je probeert nu HTTPS na te bouwen, wat prima kan, maar dan wil je misschieen gewoon https gebruiken.

http://www.ourshop.com/resources/ssl_step2.html

[Voutloos]

Dat is zeker geen nabouwen van https. Hashen vernietigt informatie, dus op zich is het een goed idee om het zo snel mogelijk te doen, tenzij je de manier van hashen geheim wil houden (maar dan kan je natuurlijk ook 2x hashen ).

Uiteraard lost https wel heel wat problemen op waar zelf niet tegenop te prutsen is.

[wizzkizz]

Verwijderd schreef op donderdag 31 januari 2008 @ 14:17:
[...]


Dit heeft volgens mij weinig effect, behalve dat je de usernames niet als plain text in de db opslaat. De username komt nog steeds als plain text over de lijn...


Persoonlijk zou ik het password op de client in js hashen en dan over de lijn gooien. In je db sla je dan alleen de hashes op. Dit zorgt ervoor dat het password niet ff uitgelezen kan worden dmv packet sniffing of als men toegang heeft tot de db.
Je kan eventueel gewoon alle data encrypten op basis van bijv session id, dit blijft overigens altijd een lastig punt. Er wordt altijd een plain text key (dus in het voorbeeld je session id) over de lijn gestuurd, welke dus gesniffed kan worden...

Ik zou persoonlijk kiezen voor én challenge/response én de formdata vervolgens AES geencrypteerd versturen naar de server om in te loggen. Je kunt als key dan een hash van het wachtwoord gebruiken. Registreren is een lastiger verhaal, omdat de server de key dan niet heeft. Dan kun je volgens mij ook volstaan met een hash van wachtwoord + seed (variant op challenge/response inloggen). Je wachtwoord gaat dan nooit in plain text over de onveilige lijn. SSL zou natuurlijk nog mooier zijn, maar TS geeft aan daar niet over te beschikken.