[PHP] Beveiliging dmv salt combineren met een enc-key, hoe?

[Verwijderd]

Ik heb de passwords van de gebruikers mbv de volgende methode opgeslagen in de database:

To make the dictionary attack more difficult, salt is used. Salt is a random string that is concatenated with passwords before being operated on by the hash function. The salt value is then stored in the user database, together with the result of the hash function. Using salt makes dictionary attacks practically impossible, as a hacker would have to compute the hashes for all possible salt values. However, salt does not help make attacks on individual passwords any harder, therefore it is important to use passwords that are difficult to guess.

Our sample user database table users will have the following three fields:


username, char(30), primary key
salt, char(10)
password_hash, char(40)

Bron: http://www.15seconds.com/issue/000217.htm

Nu wil ik deze manier van opslaan combineren met de volgende inlog structuur.

Er wordt in de gebruikte sessie een random getal gegenereerd. Als men op Login klikt, wordt voordat het form gepost word het password dmv. de volgende manier versleuteld: md5(md5($password) + $_SESSION['s_key'])
Nu wordt in het controle script het password uit de database gehaald en dan dient dit te worden vergeleken met het password wat de user heeft ingevoerd.

Hier dient het probleem zich aan. In de database is deze dmv. salt versleuteld, maar in de webapplicatie is deze dmv. een key versleuteld.
Hoe deze 2 technieken samen te gebruiken? Ik wil namelijk het password veilig opslaan in de database, en het password veilig versturen.

Ps. beide structuren zijn al geschreven, ik weet alleen niet hoe te combineren.

[stekkel]

Het is niet te combineren. md5 is one way encryptie en wanneer je je password in je db anders versleuteld dan de binnenkomende POST waarde van het versleutelde passsword dan is er geen check meer mogelijk.

Je moet dus zorgen dat het password wat je verstuurd met je inlog form te decrypten is. Je zou RC4 daarvoor kunnen gebruiken.

Wanneer je script vervolgens ook nog bekend is met de salt waarde dan kan er een check gedaan worden m.b.v. het decrypte password.

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 09:57:
Er wordt in de gebruikte sessie een random getal gegenereerd. Als men op Login klikt, wordt voordat het form gepost word het password dmv. de volgende manier versleuteld: md5(md5($password) + $_SESSION['s_key'])
Nu wordt in het controle script het password uit de database gehaald en dan dient dit te worden vergeleken met het password wat de user heeft ingevoerd.

Hier dient het probleem zich aan. In de database is deze dmv. salt versleuteld, maar in de webapplicatie is deze dmv. een key versleuteld.
Hoe deze 2 technieken samen te gebruiken? Ik wil namelijk het password veilig opslaan in de database, en het password veilig versturen.

Ps. beide structuren zijn al geschreven, ik weet alleen niet hoe te combineren.

Volgens mij gaat dat niet lukken. Wat je wilt is zo te zien een soort van APOP versleuteling. Een hash gegenereerd met een random key die door de server wordt aangeleverd. Om aan de server kant te kunnen checken of de hash klopt heb je ook aan die kant het plaintext password nodig.

Het is dus kiezen of delen, of het password versleuteld over de lijn sturen, of het password versleuteld opslaan. Waarom gebruik je niet gewoon een SSL connectie om de logingegevens uit te wisselen? Dan gaat het plaintext password SSL encrypted over de lijn.

[BlaTieBla]

Verwijderd schreef op 20 oktober 2004 @ 10:12:
[...]
Het is dus kiezen of delen, of het password versleuteld over de lijn sturen, of het password versleuteld opslaan. Waarom gebruik je niet gewoon een SSL connectie om de logingegevens uit te wisselen? Dan gaat het plaintext password SSL encrypted over de lijn.

Dat in combinatie met het in hash-vorm opslaan van het password in de database is redelijk veilig. Je kan het nog combineren met een account lock-out procedure. Na 3 keer verkeert inloggen moet je een kwartier wachten (of zo).

Het orginele verhaal neigt volgens mij naar de inlog procedure op hushmail. Daar wordt een java applet gebruikt voor de encryptie / decryptie slag.

[Verwijderd]

stekkel schreef op 20 oktober 2004 @ 10:11:
Het is niet te combineren. md5 is one way encryptie en wanneer je je password in je db anders versleuteld dan de binnenkomende POST waarde van het versleutelde passsword dan is er geen check meer mogelijk.

Je moet dus zorgen dat het password wat je verstuurd met je inlog form te decrypten is. Je zou RC4 daarvoor kunnen gebruiken.

Wanneer je script vervolgens ook nog bekend is met de salt waarde dan kan er een check gedaan worden m.b.v. het decrypte password.

RC4, dat is een manier die ik eens nader ga bekijken.

Maar wat vinden jullie bv. van mijn idee om zo de site beveiligen? Of zeggen jullie, ik zou het zo of zo doen. Ik heb geen behoefte om SSL te gebruiken.

[BlaTieBla]

Als je het wachtwoord aan de clientzijde al versleutel, dan gaat het versleutelde wachtwoord nog steeds in plain text over de lijn. Dan is het een kwestie van het versleutelde (of ge-hashte) wachtwoord afvangen en later in de encrypte vorm gewoon weer aanbieden aan de server.

Ik denk dat je vooral zelf een afweging moet maken betreffende de veiligheid van de wachtwoorden. Over het algemeen betekent veiliger duurder (ontwikkeltijd / geld voor resources etc.)

In volgorde van veiligheid (hoger is beter en vaak ook duurder):
1) password plain text over de lijn en wachtwoord plain text opslaan in DB
2) password plain text over de lijn en wachtwoord versleuteld / hashed opslaan in DB
3) password plain text via SSL versturen en wachtwoord versleuteld / hashed opslaan in DB
4) password plain text via SSL versturen en wachtwoord versleuteld / hashed opslaan in DB. Daarnaast een account lock-out optie bieden (3 keer fout is kwartier niet inloggen)
5) Sterke authenticatie (digitale certificaten / one-time passwords (bijvoorbeeld RSA SecurID tokens)
6) . . . . .


Overigens, als men de ge-hashte wachtwoorden in een database kunnen uitlezen, dan kan je er vanuit gaan dat ze ook de rest van de database uitlezen. M.a.w. een veilige website is niet alleen het veilig opslaan van passwords.

[ Voor 11% gewijzigd door BlaTieBla op 20-10-2004 10:33 ]

[Verwijderd]

BlaTieBla schreef op 20 oktober 2004 @ 10:28:
Overigens, als men de ge-hashte wachtwoorden in een database kunnen uitlezen, dan kan je er vanuit gaan dat ze ook de rest van de database uitlezen. M.a.w. een veilige website is niet alleen het veilig opslaan van passwords.

Dus het versleuteld opslaan in de database is niet zo heel belangrijk (in dit geval dan), als ze er in kunnen kunnen ze toch alles. Maar het ervoor zorgen dat ze er niet in kunnen is belangrijker. Dus het gebruik maken van een 'salt' heeft een lagere beveiligins waarde dan het versleutelen tijdens de post?

[Verwijderd]

stekkel schreef op 20 oktober 2004 @ 10:11:
Het is niet te combineren. md5 is one way encryptie en wanneer je je password in je db anders versleuteld dan de binnenkomende POST waarde van het versleutelde passsword dan is er geen check meer mogelijk.

Je moet dus zorgen dat het password wat je verstuurd met je inlog form te decrypten is. Je zou RC4 daarvoor kunnen gebruiken.

Wanneer je script vervolgens ook nog bekend is met de salt waarde dan kan er een check gedaan worden m.b.v. het decrypte password.

Heb je enig idee hoe ik RC4 kan gebruiken in PHP?

[stekkel]

Google is your friend !!

http://www.nuonce.net/code-library/1082392897.html

[BlaTieBla]

Verwijderd schreef op 20 oktober 2004 @ 11:06:
[...]


Dus het versleuteld opslaan in de database is niet zo heel belangrijk (in dit geval dan), als ze er in kunnen kunnen ze toch alles. Maar het ervoor zorgen dat ze er niet in kunnen is belangrijker. Dus het gebruik maken van een 'salt' heeft een lagere beveiligins waarde dan het versleutelen tijdens de post?

Die hash in de database is ervoor om voor de beheerders niet in de verleiding te brengen..... Daarnaast gebruiken veel gebruikers een username / password op meerdere websites. Een foute beheerder zou hiervan misbruik kunnen maken.

Wat wordt er eigenlijk op de website afgeschermd met een username en password?
Als je veiligheid wil, dan zou ik voor een (self-signed) SSL certificaat gaan in combinatie met een account-lockout procedure.

Let wel, dat account-lockout weer tot 'Denial-of-Service' van een gebruiker kan leiden.

Overigens kost een 'officieel' certificaat (door 99% van de browsers ondersteund) maar iets van 40 dollar.

[Verwijderd]

Thx, k had er ook al een gevonden met google, maar op een wazige site.
Ik vertrouwde deze niet. Nu heb ik ff wat vergelijk materiaal.

[Equator]

Is het niet zo dat je een password versleuteld (op welke manier dan ook) in de db opslaat. En bij het controleren of het password oke is, dat je het versleutelde wachtwoord uit de sessie vergelijkt met die in de database.

Dan hoef je op de server dus niets de decrypten, en kan je prima met md5 werken.

Je session ID genereer je on-the-fly met een combinatie van md5(datum+tijd+randomwaarde) welke je in een cokkie zet, en in de db.
Hierop controleer je dan of deze gelijk is.

Dat is eigenlijk de manier waarop ik het zou doen, maar ik heb het nog nooit gerealiseerd.

[Verwijderd]

stekkel schreef op 20 oktober 2004 @ 12:04:
Google is your friend !!

http://www.nuonce.net/code-library/1082392897.html

Bestaat er ook een javascript versie? Ik wil namelijk het password encrypten VOORDAT het wordt gepost. Dit is volgens mij alleen mogelijk dmv. javascript.
Tenzij jij een manier weet om deze te encrypten met php.

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 12:40:
Bestaat er ook een javascript versie? Ik wil namelijk het password encrypten VOORDAT het wordt gepost. Dit is volgens mij alleen mogelijk dmv. javascript.
Tenzij jij een manier weet om deze te encrypten met php.

Volgens mij heeft dat geen zin. RC4 is een symmetrische cypher. Zowel de verstuurder als de ontvanger moeten dus dezelfde key hebben. Dat betekent hier dat de key door de server naar de client moet worden verzonden (in de webpagina).

Een sniffer beschikt dan dus over zowel de key als de (javascript) encryptiecode en kan zelf het wachtwoord ontsleutelen.

Een one-way hash (md5) is hiervoor een prima methode (omdat er nooit het wachtwoord uit afgeleid kan worden), maar zoals gezegd, daarvoor heb je dus op de server het plaintext wachtwoord nodig.

De enige praktische manier om symmetrische encryptie over http connecties veilig te doen is om een asymmetrisch algoritme te gebruiken voor de (random) key uitwisseling. Zo'n systeem hebben we al en het heet SSL (gebruikt trouwens ook RC4 iirc) ;-)

Het is jammer dat SSL voor jou blijkbaar geen optie is...

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 13:11:
[...]

Volgens mij heeft dat geen zin. RC4 is een symmetrische cypher. Zowel de verstuurder als de ontvanger moeten dus dezelfde key hebben. Dat betekent hier dat de key door de server naar de client moet worden verzonden (in de webpagina).

Een sniffer beschikt dan dus over zowel de key als de (javascript) encryptiecode en kan zelf het wachtwoord ontsleutelen.

Een one-way hash (md5) is hiervoor een prima methode (omdat er nooit het wachtwoord uit afgeleid kan worden), maar zoals gezegd, daarvoor heb je dus op de server het plaintext wachtwoord nodig.

De enige praktische manier om symmetrische encryptie over http connecties veilig te doen is om een asymmetrisch algoritme te gebruiken voor de (random) key uitwisseling. Zo'n systeem hebben we al en het heet SSL (gebruikt trouwens ook RC4 iirc) ;-)

Het is jammer dat SSL voor jou blijkbaar geen optie is...

Ik verzend de key dus niet hoor.

De random key wordt in een sessie opgeslagen en niet mee verstuurd.
Tijdens het veriferen van het password wordt de key uit de sessie gebruikt.

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 13:16:
Ik verzend de key dus niet hoor.

De random key wordt in een sessie opgeslagen en niet mee verstuurd.
Tijdens het veriferen van het password wordt de key uit de sessie gebruikt.

Ah, je bedoelt *tijdens* de sessie? In dat geval gebruik je gewoon een random gegenereerd groot getal dat je ook in de DB opslaat. Hoeft niets met het password te maken te hebben (liever niet).

Maar we hadden het toch over de initiele login (password uitwisseling)? Volgens mij heb je daarvoor maar een 3 echte opties:
- Alles plaintext
- Plaintext over SSL
- One way hash (waarbij het pw op de server dus plaintext moet zijn)

(One way hash over SSL heeft natuurlijk geen zin)

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 13:21:
[...]

Ah, je bedoelt *tijdens* de sessie? In dat geval gebruik je gewoon een random gegenereerd groot getal dat je ook in de DB opslaat. Hoeft niets met het password te maken te hebben (liever niet).

Maar we hadden het toch over de initiele login (password uitwisseling)? Volgens mij heb je daarvoor maar een 3 echte opties:
- Alles plaintext
- Plaintext over SSL
- One way hash (waarbij het pw op de server dus plaintext moet zijn)

(One way hash over SSL heeft natuurlijk geen zin)

Ok, ik probeer nu dit:

1) De user klikt op "Login"
2) voordat de post wordt uitgevoerd word het password dmv. rc4 + Key(key wordt opgeslagen in de sessie) versleuteld
3) post wordt uitgevoerd naar de controle pagina, key wordt NIET mee verstuurd
4) in de controle pagina wordt het dmv een met 'salt' versleuteld password opgehaald uit de database voor de betreffende user
5) Het dmv rc4 versleutelde password wordt gedecrypt met de key welke in de sessie opgeslagen is
6) het gedecrypte password wordt dmv de opgehaalde 'salt' versleuteld
7) versleutelde password wordt vergeleken met het versleutelde password uit de database
passwords matchen -> toegang
passwords matchen niet -> toegang weigeren

Dit is hoe ik het wil gaan doen. Alleen het gedeelte van rc4 moet ik nog maken.

Wat vinden jullie van deze aanpak?

[ Voor 3% gewijzigd door Verwijderd op 20-10-2004 13:41 ]

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 13:36:
[...]


Ok, ik probeer nu dit:

1) De user klikt op "Login"
2) voordat de post wordt uitgevoerd word het password dmv. rc4 + Key(key wordt opgeslagen in de sessie) versleuteld

Hier gaat het fout volgens mij. Die key moet nl. aan de browser gecommuniceerd worden (als cookie of ergens in de HTML code) op dat moment kan hij door een sniffer opgepikt worden.

3) post wordt uitgevoerd naar de controle pagina, key wordt NIET mee verstuurd

M.b.v. de eerder gevangen sleutel kan de sniffer nu het wachtwoord decrypten.

4) in de controle pagina wordt het dmv een met 'salt' versleuteld password opgehaald uit de database voor de betreffende user
5) Het dmv rc4 versleutelde password wordt gedecrypt met de key welke in de sessie opgeslagen is
6) het gedecrypte password wordt dmv de opgehaalde 'salt' versleuteld
7) versleutelde password wordt vergeleken met het versleutelde password uit de database
passwords matchen -> toegang
passwords matchen niet -> toegang weigeren

Dit is hoe ik het wil gaan doen. Alleen het gedeelte van rc4 moet ik nog maken.

Wat vinden jullie van deze aanpak?

Volgens mij zit je dus echt verkeerd met die RC4 implementatie. Die maakt het leven van een sniffer weliswaar iets moeilijker, maar het blijft erg eenvoudig te kraken.

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 13:59:
[...]

Hier gaat het fout volgens mij. Die key moet nl. aan de browser gecommuniceerd worden (als cookie of ergens in de HTML code) op dat moment kan hij door een sniffer opgepikt worden.

[...]

M.b.v. de eerder gevangen sleutel kan de sniffer nu het wachtwoord decrypten.

[...]

Volgens mij zit je dus echt verkeerd met die RC4 implementatie. Die maakt het leven van een sniffer weliswaar iets moeilijker, maar het blijft erg eenvoudig te kraken.

Ik gebruik eerst deze functie om een random getal te genereren.
function randomValue(){
$random_value = (double)microtime()*1000000000;
srand($random_value);
return md5(rand());
}
Hierna plant ik de waarde in de sessie: $_SESSION['s_enc_key'] = randomValue();

is dit zo onveilig dan? Is dit te sniffen?
Maarja, ik probeer het zo, het enige wat ik nodig heb is een javascript versie van rc4 denk ik.

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 14:06:
[...]


Ik gebruik eerst deze functie om een random getal te genereren.
function randomValue(){
$random_value = (double)microtime()*1000000000;
srand($random_value);
return md5(rand());
}
Hierna plant ik de waarde in de sessie: $_SESSION['s_enc_key'] = randomValue();

is dit zo onveilig dan? Is dit te sniffen?
Maarja, ik probeer het zo, het enige wat ik nodig heb is een javascript versie van rc4 denk ik.

Tot dusver is het allemaal erg veilig. Het gaat pas fout als je je randomgetal aan de javascript code die op de browser draait gaat doorgeven. Dan moet je hem toch echt over het (onveilige) net sturen! Je PHP sessievariabelen zijn nl. niet vanuit javascript te benaderen... (server-side vs client-side)

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 14:16:
[...]

Tot dusver is het allemaal erg veilig. Het gaat pas fout als je je randomgetal aan de javascript code die op de browser draait gaat doorgeven. Dan moet je hem toch echt over het (onveilige) net sturen! Je PHP sessievariabelen zijn nl. niet vanuit javascript te benaderen... (server-side vs client-side)

Ok, nu moet ik je toch gelijk geven.

Heb je misschien nog ergens een javascript versie van rc4 encrypt decrypt liggen

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 14:27:
Ok, nu moet ik je toch gelijk geven.

Heb je misschien nog ergens een javascript versie van rc4 encrypt decrypt liggen

Nee, maar dit is de eerste 'rc4 javascript' hit in Google:

http://home.zonnet.nl/MAvanEverdingen/Code/

Hij heeft ook nog RSA (asymmetrisch algoritme) javascript code, dus je zou *toch* een veilige oplossing kunnen maken door je server public key in je html mee te sturen en je wachtwoord daarmee te versleutelen. Dan kan het nl. alleen door de bezitter van de private key worden ontcijfert. RC4 heb je dan helemaal niet meer nodig.

Laat het even weten als je dit werkend hebt, want dat begint dan best een mooie implementatie te worden (ik heb dat iig nog nooit ergens gezien).

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 14:35:
[...]

Nee, maar dit is de eerste 'rc4 javascript' hit in Google:

http://home.zonnet.nl/MAvanEverdingen/Code/

Hij heeft ook nog RSA (asymmetrisch algoritme) javascript code, dus je zou *toch* een veilige oplossing kunnen maken door je server public key in je html mee te sturen en je wachtwoord daarmee te versleutelen. Dan kan het nl. alleen door de bezitter van de private key worden ontcijfert. RC4 heb je dan helemaal niet meer nodig.

Laat het even weten als je dit werkend hebt, want dat begint dan best een mooie implementatie te worden (ik heb dat iig nog nooit ergens gezien).

Die had ik ook gevonden, maar ik kan geen wijs uit die site hoor.
Ik kan hier volgens mij niks downloaden. Of lukt jou dat wel? Ik kan geen javascript file vinden.

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 14:40:
[Die had ik ook gevonden, maar ik kan geen wijs uit die site hoor.
Ik kan hier volgens mij niks downloaden. Of lukt jou dat wel? Ik kan geen javascript file vinden.

http://home.zonnet.nl/MAvanEverdingen/Code/code.html

View source?

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 14:44:
[...]


http://home.zonnet.nl/MAvanEverdingen/Code/code.html

View source?

Nou, ik kan er geen wijs uit.

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 14:48:
[...]


Nou, ik kan er geen wijs uit.

Als je wilt programmeren moet je je nou eenmaal af en toe ergens in vastbijten en encryprie is nou eenmaal niet het makkelijkste onderwerp. ;-)

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 14:54:
[...]

Als je wilt programmeren moet je je nou eenmaal af en toe ergens in vastbijten en encryprie is nou eenmaal niet het makkelijkste onderwerp. ;-)

Nou, sla mij maar ....
Als je mij kan vertellen waar ik een werkend .js filetje kan downe ben je een goeie.

[Verwijderd]

Verwijderd schreef op 20 oktober 2004 @ 15:17:
Nou, sla mij maar ....
Als je mij kan vertellen waar ik een werkend .js filetje kan downe ben je een goeie.

Geen idee, ik krijg die demo zo snel niet eens werkend.

Als ik jou was zou ik die Michiel even mailen.

[gorgi_19]

3pinter, wat wil je nu? Javascript oplossing, of PHP? En als het hier gaat richting het vragen c.q. zoeken naar kant en klare scripts, gaat deze onherroepelijk dicht.

[Verwijderd]

gorgi_19 schreef op 20 oktober 2004 @ 15:25:


3pinter, wat wil je nu? Javascript oplossing, of PHP? En als het hier gaat richting het vragen c.q. zoeken naar kant en klare scripts, gaat deze onherroepelijk dicht.

Zou leuk zijn ja, maar volgens mij is dat besproken in de policy.
Nee, ik kan er geen wijs uit, uit die site. Daar wil ik dus mn script vandaan halen, maar ken em niet vinden.

[stekkel]

Verwijderd schreef op 20 oktober 2004 @ 15:32:
[...]


Zou leuk zijn ja, maar volgens mij is dat besproken in de policy.
Nee, ik kan er geen wijs uit, uit die site. Daar wil ik dus mn script vandaan halen, maar ken em niet vinden.

http://home.zonnet.nl/MAvanEverdingen/Code/

[BlaTieBla]

Voor het geheel blijft nog steeds gelden dat je met een sniffer de boel kan omzeilen. Sessie ID's zijn met sniffers af te vangen en het 'encrypte' wachtwoord ook. Daarna is het een 'replay' doen van de data en je bent nog steeds binnen.

Alles wat met http te maken heeft is af te vangen en opnieuw af te spelen. Alleen de zogenaamde one-time passwords geven hier enige veiligheid (even geen man-in-the-middle-attack in het achterhoofd houden )

Je toch zal naar een SSL verbinding moeten gaan kijken om er voor te zorgen dat het verkeer niet afgevangen kan worden. Pas dan kan je het redelijk goed dicht timmeren.

Overigens is de materie 'an sich' wel leerzaam. Zolang je maar in het achterhoofd hou dat iedere oplossing zonder SSL en/of one-time passwords niet veilig is (veiligheid is overigens wel relatief )

Nogmaals de veiligheid van de inlogprocedures moeten wel in verhouding staan tot datgene wat beveiligd wordt (de data).

[TheBorg]

Ik heb het anders opgelost en het is naar mijn mening vrij waterdicht.

Op het inlogscherm wordt een php script als plaatje ge-src-ed. Op het moment dat het plaatje word aangeroepen word er een keyphrase gegenereerd. Deze keyphrase word md5 samen met het IP van de gebruiker opgeslagen in een database. Dan wordt het plaatje (de keyphrase) in de browser weergegeven.

De user typt zijn username/password in en typt de keyphrase over, dit geheel wordt in één md5 hash verzonden (noem ik de key).

Sniffen en replay heeft geen zin. Met sniffen kom je niet te weten wat de username/password/keyphrase was. Een replay is niet mogelijk omdat voor elke login een andere key vereist is, en na de login is de key ongeldig. Dus zodra je de key hebt kunnen sniffen is deze al ongeldig. Bovendien is het geheel ook nog IP gebonden.

[BlaTieBla]

Op die manier is de login idd redelijk dichtgetimmerd. Alleen heb je nu een veilige login procedure, maar de data is voor de rest nog steeds af te vangen.

Komt overeen met de waardevolle spullen in een houten doosje doen en die afsluiten met het allerduurste slot. Leuk slot, maar op een eenvoudig houten kisje is dat overkill

Voor de rest is het wel leuk experimenteren met authenticatie technieken.

[ Voor 92% gewijzigd door BlaTieBla op 21-10-2004 18:53 ]

[Verwijderd]

TheBorg schreef op 21 oktober 2004 @ 18:19:
Ik heb het anders opgelost en het is naar mijn mening vrij waterdicht.

Op het inlogscherm wordt een php script als plaatje ge-src-ed. Op het moment dat het plaatje word aangeroepen word er een keyphrase gegenereerd. Deze keyphrase word md5 samen met het IP van de gebruiker opgeslagen in een database. Dan wordt het plaatje (de keyphrase) in de browser weergegeven.

De user typt zijn username/password in en typt de keyphrase over, dit geheel wordt in één md5 hash verzonden (noem ik de key).

Sniffen en replay heeft geen zin. Met sniffen kom je niet te weten wat de username/password/keyphrase was. Een replay is niet mogelijk omdat voor elke login een andere key vereist is, en na de login is de key ongeldig. Dus zodra je de key hebt kunnen sniffen is deze al ongeldig. Bovendien is het geheel ook nog IP gebonden.

Nu ben je weer gewoon terug bij de one-way hash oplossing waar je mee begonnen was. Een prima methode, maar je moet op de server je wachtwoord dus in plaintext opslaan.

Dat plaatje klinkt leuk maar voegt niet echt iets toe in dit geval. Het plaatje is net zo goed te sniffen als een ascii string. De beveiliging zit in de one-way hash.

[TheBorg]

Verwijderd schreef op 21 oktober 2004 @ 21:38:
[...]

Nu ben je weer gewoon terug bij de one-way hash oplossing waar je mee begonnen was. Een prima methode, maar je moet op de server je wachtwoord dus in plaintext opslaan.

Dat plaatje klinkt leuk maar voegt niet echt iets toe in dit geval. Het plaatje is net zo goed te sniffen als een ascii string. De beveiliging zit in de one-way hash.

De password wordt 2x gehashed voor verzenden en word dus niet in plain text opgeslagen op de server. Het plaatje kun je wel sniffen maar dat boeit niet want de login key is maar 1 maal geldig. Het is alleen een methode om brute-force aanvallen te vermoeilijken.