[PHP] Versleuteld inloggen, toch wachtwoord achterhalen*

[Priet]

Gegeven deze situatie:

code:

---------------------
   CLIENT
---------------------
     |
     | verstuurt inlognaam + wachtwoord
     |
---------------------
   WEBSITE
---------------------
     |
     | verstuurt inlognaam + wachtwoord via LDAP
     |
---------------------
   AD
---------------------

De gebruiker (client) logt in op een website. De gebruikersgegevens zijn opgeslagen in een Windows 2003 Server Active Directory, deze dienen overeen te komen met de ingevoerde inloggegevens.

Als ik alles in plain-text doorstuur gaat alles prima: de client geeft zijn wachtwoord aan de website en de website geeft het wachtwoord door aan de AD (via ldap_bind()). De gebruiker is vervolgens succesvol ingelogd.

Maar ik heb liever niet dat de wachtwoord open en bloot het internet over geslingerd worden. Nu kan ik wel het wachtwoord via bijvoorbeeld een challenge-reponse hashen zodat nooit het wachtwoord wordt overgestuurd, maar dan kan ik niet inloggen via LDAP, daar is immers het échte wachtwoord voor nodig.

HTTP Basic Authentication, HTTP Digest Authentication en een JS Challenge-Response systeem via Javascript werken niet omdat in alle gevallen de website niet beschikt over het echte wachtwoord (alleen een hash). Basic is niet voldoende omdat het niet beveiligd is.

HTTPS/SSL is natuurlijk een optie, maar ik had liever een oplossing gevonden waarvoor SSL niet noodzakelijk is.

Hoe kan ik er nu voor zorgen dat het wachtwoord níet onversleuteld wordt overgestuurd maar de website toch het echte wachtwoord binnenkrijgt zodat het hiermee kan inloggen in de AD?

[Grijze Vos]

encryptie gebruiken ipv hashing?

[Verwijderd]

Is de server niet in staat nog een "bewerking" uit te voeren op de data alvorens het wachtwoord te versturen? Het is een beetje houtje touwtje oplossing, maar je kan natuurlijk een omkeerbare encryptiemethode toepassen, alhoewel dit je nooit kan garanderen dat "iemand" achterhaald welke methode je hiervoor toepast, ook al zou je gebruik maken van een challenge/response systeem. Ik zou toch SSL gebruiken. (eventueel VPN overwegen? of is dat overkill voor jouw toepassing?)

[Verwijderd]

@Grijze Vos, ik ben alleen bang dat de clients de key dan al in hun bezit moeten hebben, anders moet je deze ook via het web versturen, als je dit zou kunnen afvangen + de reply, zou je als je de encryptie methode weet, het password dus weer kunnen herleiden... of zie ik dat verkeerd?

[Verwijderd]

SSL lijkt niet heel ingewikkeld. De guide op http://adldap.sourceforge.net/ldap_ssl.php is iig niet zo lang

Ben wel benieuwd naar je uitkomst, wil zelf ook zoiets opzetten, maar heb wegens gebrek aan tijd en fatsoenlijke hosting nog geen poging gedaan.

[Grijze Vos]

Verwijderd schreef op dinsdag 05 december 2006 @ 12:12:
@Grijze Vos, ik ben alleen bang dat de clients de key dan al in hun bezit moeten hebben, anders moet je deze ook via het web versturen, als je dit zou kunnen afvangen + de reply, zou je als je de encryptie methode weet, het password dus weer kunnen herleiden... of zie ik dat verkeerd?

Neuh. Je hebt een public key waarmee je de data encrypt, en een private key waarmee je de data decrypt. De public key mag iedereen zien, kun je verder weinig mee.

Wat je dan doet is de public key meesturen naar de client toe, die gebruikt die dan om te encrypten, en de server kan dan met zijn private key de message weer decrypten.

[Woy]

Grijze Vos schreef op dinsdag 05 december 2006 @ 12:32:
[...]

Neuh. Je hebt een public key waarmee je de data encrypt, en een private key waarmee je de data decrypt. De public key mag iedereen zien, kun je verder weinig mee.

Wat je dan doet is de public key meesturen naar de client toe, die gebruikt die dan om te encrypten, en de server kan dan met zijn private key de message weer decrypten.

Dat is idd wel de beste methode als je perse het wachtwoord moet kunnen achterhalen. Zorg er dan wel voor dat je iest van een salt gebruikt die de server bepaald. Anders ben je alsnog gevoelig voor repitition ( Het geencrypte wachtwoord is immers altijd hetzelfde dus daar zou je ook mee kunnen inloggen. )

Dus

Server stuurt public key en salt ( Deze is tijdelijk en eenmalig geldig )

Client pakt wachtwoord plakt daar de salt aan vast en encrypt dit met public key
Client stuurt geencrypte package op naar server

Server decrypt met de private key en haalt de salt er weer vanaf.

Het voordeel hiervan is is dat de data die je verstuurt per inlog poging verschilt.

[ Voor 19% gewijzigd door Woy op 05-12-2006 12:46 ]

[Grijze Vos]

Klopt idd wat je zegt rwb.

@TS, kijk gewoon even een keer naar hoe bijv. PGP dit doet, leer je veel van.

[CH4OS]

Misschien is een VPN ook nog een optie?
Dan kan je tóc secure werken, zonder een encryptie of hash en je hoeft ook geen HTTPS/SSL te hebben...

[Priet]

Het probleem van encriptie leek mij dat telkens dezelfde sleutel wordt gebruikt, en dat is natuurlijk nog steeds te onderscheppen en te hergebruiken. Met public/private keys heb je dat probleem niet, maar dat is volgens mij zo r*te ingewikkeld te implementeren

VPN is geen optie en LDAP via SSL aanspreken is hier niet van toepassing. Ik denk dat ik mij maar meer moet verdiepen in het private/public key gebeuren...

[ Voor 10% gewijzigd door Priet op 05-12-2006 13:56 ]

[Cloud]

Priet schreef op dinsdag 05 december 2006 @ 13:55:
Met public/private keys heb je dat probleem niet, maar dat is volgens mij zo r*te ingewikkeld te implementeren

Dat valt wel mee Zijn genoeg links over te vinden hoor. Deze van IBM lijkt mij wel een mooie start met ook nog veel resources. En google helpt natuurlijk ook bergen

[riddles]

Het probleem hier is de communicatie tussen de browser en de webserver (php). De browser zal dus een soort reversible encrypt uit moeten voeren (in Javascript). De enige juiste manier is volgens mij asymmetrische encryptie, maar ik kan zo snel geen voorbeeld vinden in Javascript.

Persoonlijk zou ik trouwens nooit laten inloggen naar een AD over het internet zonder gebruik van SSL.

[Grijze Vos]

riddles schreef op dinsdag 05 december 2006 @ 14:21:
Het probleem hier is de communicatie tussen de browser en de webserver (php). De browser zal dus een soort reversible encrypt uit moeten voeren (in Javascript). De enige juiste manier is volgens mij asymmetrische encryptie, maar ik kan zo snel geen voorbeeld vinden in Javascript.

Persoonlijk zou ik trouwens nooit laten inloggen naar een AD over het internet zonder gebruik van SSL.

Waarom niet? SSL is ook 'maar' een vorm van encryptie hoor.

[Priet]

riddles schreef op dinsdag 05 december 2006 @ 14:21:
Het probleem hier is de communicatie tussen de browser en de webserver (php). De browser zal dus een soort reversible encrypt uit moeten voeren (in Javascript). De enige juiste manier is volgens mij asymmetrische encryptie, maar ik kan zo snel geen voorbeeld vinden in Javascript.

Persoonlijk zou ik trouwens nooit laten inloggen naar een AD over het internet zonder gebruik van SSL.

Ik heb zojuist een aantal voorbeelden gevonden van het gebruik van encryptie met Javascript:

Google naar 'javascript encryption public key'

Daarmee zou het dus lukken om de het inlogform beveiligd op de webserver te krijgen, toch

Dan stap 2: de server (PHP) moet het weer zien te decrypten. Maar het lijkt erop of PHP dit in tegenstelling tot Javascript niet zelf kan, het moet via de shell GPG de opdracht geven het geheel te decrypten.

Ik kom veel sites tegen die tot in detail het encrypten en decrypten van gegevens demonstreren. Maar ze gaan er allemaal vanuit dat het formulier via SSL beveiligd moet worden. Als ik het inlogformulier via SSL zou beveiligen zou ik dat met de rest van de website ook wel doen

[Cloud]

Priet schreef op dinsdag 05 december 2006 @ 14:35:
[...]


Ik heb zojuist een aantal voorbeelden gevonden van het gebruik van encryptie met Javascript:

Google naar 'javascript encryption public key'

Daarmee zou het dus lukken om de het inlogform beveiligd op de webserver te krijgen, toch

Dan stap 2: de server (PHP) moet het weer zien te decrypten. Maar het lijkt erop of PHP dit in tegenstelling tot Javascript niet zelf kan, het moet via de shell GPG de opdracht geven het geheel te decrypten.

Ik kom veel sites tegen die tot in detail het encrypten en decrypten van gegevens demonstreren. Maar ze gaan er allemaal vanuit dat het formulier via SSL beveiligd moet worden. Als ik het inlogformulier via SSL zou beveiligen zou ik dat met de rest van de website ook wel doen

Je bent op de goede weg Misschien dat je hier wat aan hebt?

Succes iig!

[Priet]

Bedankt voor link Maar ook daar blijkt uit dat PHP het zelf niet kan: het heeft een externe library nodig.

Als zelfs Javascript het kan, waarom doet PHP dan zo moeilijk?

[Cloud]

Priet schreef op dinsdag 05 december 2006 @ 15:54:
Bedankt voor link Maar ook daar blijkt uit dat PHP het zelf niet kan: het heeft een externe library nodig.

Als zelfs Javascript het kan, waarom doet PHP dan zo moeilijk?

Op zich doet PHP niet zozeer moeilijk. In de opensource wereld heb je dit gewoon wel vaker. Javascript wordt (bij mijn weten) verder niet meer ontwikkeld maar PHP wel constant. En door middel van libraries is dit natuurlijk veel makkelijker te regelen. Anders moet je voor elke kleine update weer een nieuwe PHP releasen. Nu is het alleen de library die geupdate kan worden. Er is dus geen verplichting. Uiteindelijk kun je dus zelf kiezen wat je wél en wat je níet gebruikt en dat scheelt

Nadeel is natuurlijk wel dat libraries dus vaak geïnstalleerd dienen te worden door je hostingprovider...

[CH4OS]

wolkje schreef op dinsdag 05 december 2006 @ 16:03:
Nadeel is natuurlijk wel dat libraries dus vaak geïnstalleerd dienen te worden door je hostingprovider...

Hangt er van af welke library of module het is...
GD bijvoorbeeld moet je idd apart installeren, maar Smarty kan je gewoon middels een PHP file te laden gewoon werkend krijgen evenals PEAR...

[Priet]

Precies! Zijn de methoden van GPG zo ingewikkeld dat PHP ze met native-PHP-functies niet af kan handelen? Javascript lukt het immers toch ook... dat is wat ik hier zo raar aan vind.

[CH4OS]

Priet schreef op dinsdag 05 december 2006 @ 16:38:
Precies! Zijn de methoden van GPG zo ingewikkeld dat PHP ze met native-PHP-functies niet af kan handelen? Javascript lukt het immers toch ook... dat is wat ik hier zo raar aan vind.

Heb je misschien wat aan dit? Of deze? En anders heb je denk ik heel veel aan deze
[google=PHP GPG]

[Priet]

Dat is inderdaad wat ik zoek, maar dan zonder het gebruik van de gpg executable

[DroogKloot]

Er is IIRC geen pubkey-crypto library voor PHP, die zul je zelf moeten schrijven.

[ Voor 3% gewijzigd door DroogKloot op 05-12-2006 17:57 ]

[Woy]

kijk anders eens hier PEAR::Crypt_RSA

[ATS]

Het is echt enorm makkelijk om bij het gebruik van encryptie fouten te maken die zorgen dat je alsnog kwetsbaar bent. Daarom is het in het algemeen een goed idee om waar maar mogelijk gebruik te maken van standaardoplossingen, zoals SSL. Je moet echt heel goede redenen hebben om je eigen oplossing te gaan bouwen.

[Equator]

Als je de data niet in clear text over de lijn wilt laten gaan, dan kan je 2 dingen doen.

Moeilijkste manier:
Eigen crypto oplossing verzinnen of bestaande oplossing gebruiken, en dan nog tegen een probleem aan lopen dat je de sleutel over de lijn moet sturen. Dit soort dingen zijn leuk als je data versleuteld wilt opslaan in een textfile/database. Als je de data op een client versleuteld en je wilt deze op de server ontsleutelen moet je of de symmetrische sleutel alsnog over de lijn gooien of een asymmetrische versleuteling gebruiken. * Equator gaat wel eens kijken naar die RSA module van PEAR

Makkelijkste oplossing:
SSL inplementeren: Alle data loopt dan over een reeds versleutelde verbinding. 128bit symmetrische sleutel heb je niet binnen 1 seconden gekaakt, en langer duurt het niet om je password over te sturen.
De SSL sessie heeft al gezorgd voor een veilige sleuteltransmissie dus daar hoef je niet meer over te denken. De server krijgt gewoon nog clear-text gegevens binnen en kan daar meteen zijn ding mee doen.

[Woy]

Equator schreef op woensdag 06 december 2006 @ 11:53:
128bit symmetrische sleutel heb je niet binnen 1 seconden gekaakt, en langer duurt het niet om je password over te sturen.

Dat het langer als 1 seconde duurt om het te kraken haalt niet uit. Als je de data opvangt en je doet er een week over om de versleuteling te kraken dan heb je nog steeds het wachtwoord. Je moet er dus voor zorgen dat de security maatregel die je neemt langer duurt om te kraken dan dat het wachtwoord nuttig is om te weten.

[ReverendBizarre]

SSL is gebaseerd op public key encryption en is dus asymmetrisch, dat is juist waarom het zo geschikt is voor het beveiligen van een verbinding tussen twee punten omdat je de daardoor de sleutel die gebruikt wordt voor het decrypten niet hoeft te verzenden (je verstuurt immers alleen je public key en ontvangt de public key van de andere partij).

En om de bijbehorende private key te brute forcen kan je dus wel vergeten. De keyspace van een 128 bit sleutel is zo belachelijk groot dat het op een normale PC een paar miljoen jaar zou duren om alle mogelijkheden uit te proberen. Kijk maar naar hoe enorm langzaam het RC-72 project gaat, en dat gaat dan met duizenden computers tegelijk. De tijd die dat kost moet je nog eens een keer maal 2^32 doen om de tijd te krijgen die het zou kosten om een 128 bit keyspace volledig te verkennen.

[BCC]

Waarom zet je die site dan niet gewoon op HTTPS? Dan wordt alle SSL door Apache / de Browser netjes voor je afgehandeld.

[Woy]

BCC schreef op woensdag 06 december 2006 @ 14:23:
Waarom zet je die site dan niet gewoon op HTTPS? Dan wordt alle SSL door Apache / de Browser netjes voor je afgehandeld.

Mischien omdat een certificaat aanschaffen ook geld kost. Al kan ik me niet echt voorstellen dat dat een probleem moet vormen als het om een proffesionele site gaat.

[Equator]

rwb schreef op woensdag 06 december 2006 @ 13:07:
[...]

Dat het langer als 1 seconde duurt om het te kraken haalt niet uit. Als je de data opvangt en je doet er een week over om de versleuteling te kraken dan heb je nog steeds het wachtwoord. Je moet er dus voor zorgen dat de security maatregel die je neemt langer duurt om te kraken dan dat het wachtwoord nuttig is om te weten.

Daar heb je op zich een goed punt. Echter is ook een 128 bit symmetrische sleutel niet zo gemakkelijk te kraken. Bovendien heb je in SSL met 2 verschillende sleutels te maken, wat het nog iets lastiger maakt..
1 server-read / client-write sleutel
1 server-write / client-read sleutel

CAIRATH schreef op woensdag 06 december 2006 @ 14:17:
SSL is gebaseerd op public key encryption en is dus asymmetrisch, dat is juist waarom het zo geschikt is voor het beveiligen van een verbinding tussen twee punten omdat je de daardoor de sleutel die gebruikt wordt voor het decrypten niet hoeft te verzenden (je verstuurt immers alleen je public key en ontvangt de public key van de andere partij).

En om de bijbehorende private key te brute forcen kan je dus wel vergeten. De keyspace van een 128 bit sleutel is zo belachelijk groot dat het op een normale PC een paar miljoen jaar zou duren om alle mogelijkheden uit te proberen. Kijk maar naar hoe enorm langzaam het RC-72 project gaat, en dat gaat dan met duizenden computers tegelijk. De tijd die dat kost moet je nog eens een keer maal 2^32 doen om de tijd te krijgen die het zou kosten om een 128 bit keyspace volledig te verkennen.

Misschien overbodig: Maar je weet dat er alleen gebruik wordt gemaakt van asymmetrische encryptie voor de veilige sleuteloverdracht
Daarna wordt er gewoon een blockencryptie gedaan met een symmetrische sleutel. Zou je data werkelijk gaan block-encrypten met een een asymmetrische sleutel dan wordt het onwerkbaar (factor 1000 trager)

rwb schreef op woensdag 06 december 2006 @ 15:41:
[...]

Mischien omdat een certificaat aanschaffen ook geld kost. Al kan ik me niet echt voorstellen dat dat een probleem moet vormen als het om een proffesionele site gaat.

Das niet helemaal waar. Een certificaat is gewoon gratis. Kan je zelf maken met een Microsoft CA of met OpenSSL (Zie signature)
Dat het certificaat dan niet ondertekend is door een als vertrouwd aangemerkte certificeringsinstantie maakt het niet veiliger. Je moet alleen uitkijken dat je inderdaad een certificaat gebruikt wat aangevraagd/gemaakt is voor de correcte website.
Daarnaast kan je met het vereissen van clientcertificates en wat controle op de RootCA het e.e.a. goed veilig krijgen.

[ Voor 16% gewijzigd door Equator op 06-12-2006 16:31 ]

[Woy]

Equator schreef op woensdag 06 december 2006 @ 16:25:
[...]
Das niet helemaal waar. Een certificaat is gewoon gratis. Kan je zelf maken met een Microsoft CA of met OpenSSL (Zie signature)
Dat het certificaat dan niet ondertekend is door een als vertrouwd aangemerkte certificeringsinstantie maakt het niet veiliger. Je moet alleen uitkijken dat je inderdaad een certificaat gebruikt wat aangevraagd/gemaakt is voor de correcte website.
Daarnaast kan je met het vereissen van clientcertificates en wat controle op de RootCA het e.e.a. goed veilig krijgen.

Ok maar een niet door een TTP uitgegeven certificaat zal vaak niet acceptabel zijn omdat je dan of op alle pc's dat certificaat zal moeten trusten of elke keer zo'n vervelend schermpje weg moeten klikken.

[Equator]

rwb schreef op woensdag 06 december 2006 @ 17:05:
[...]

Ok maar een niet door een TTP uitgegeven certificaat zal vaak niet acceptabel zijn omdat je dan of op alle pc's dat certificaat zal moeten trusten of elke keer zo'n vervelend schermpje weg moeten klikken.

offtopic:
Tja, maar als jij je Root CA mee stuurt, dan hoeft men maar 1 keer op Install certificate te klikken.
En aan de andere kant weet je dan wel dat je een secure verbinding maakt.

[Fuzzillogic]

Je kunt ook *inloggen* met een certificaat. Op de inlogpagina geeft je browser je dan lijstje met geinstalleerde certificaten, waaruit je dan eentje kiest. Het werkt (zelfs) in Internet Explorer. Nadeel is wel dat je je certificaat "bij je" moet hebben, hetzij op een USB token, hetzij geinstalleerd op je PC. Het is wel behoorlijk veilig daarmee.
Hoe het exact werkt heb ik me verder nog niet in verdiept, maar kan het wel even uitzoeken mocht er intersse zijn.

JS Challenge-Response systeem via Javascript werken niet omdat in alle gevallen de website niet beschikt over het echte wachtwoord (alleen een hash).

Dat maakt toch niet uit? Die hash is toch ook een "wachtwoord".

server -> client: random_code
client -> server: hash( hash(password) + random_code)

@server controleren of hash(hashedPasswordInDB + random_code) overeenkomt.

Of eh.. zie ik het nou verkeerd?

[Woy]

Fuzzillogic schreef op woensdag 06 december 2006 @ 22:09:
Dat maakt toch niet uit? Die hash is toch ook een "wachtwoord".

server -> client: random_code
client -> server: hash( hash(password) + random_code)

@server controleren of hash(hashedPasswordInDB + random_code) overeenkomt.

Of eh.. zie ik het nou verkeerd?

Nee dat zie je goed. Je moet hiermee alleen nog steeds wel oppassen dat ook je hash niet in handen van derde komt aangezien dat dan ook goed genoeg is om in te loggen.

Equator schreef op woensdag 06 december 2006 @ 19:59:
[...]

offtopic:
Tja, maar als jij je Root CA mee stuurt, dan hoeft men maar 1 keer op Install certificate te klikken.
En aan de andere kant weet je dan wel dat je een secure verbinding maakt.

offtopic:
Als je applicatie door een beperkt gezelschap gebruikt wordt of alleen een hobby project is dan is dat inderdaad afdoende. Maar als er ook klanten op zo'n site komen vindt ik het niet echt proffesioneel over komen en dan geef ik liever wat geld uit.

[Priet]

rwb schreef op dinsdag 05 december 2006 @ 17:54:
kijk anders eens hier PEAR::Crypt_RSA

Ik zei toch dat het r*te ingewikkeld was Ik ga eens zoeken naar voorbeelden van deze class. En anders moet ik toch eens naar de GPG via de shell gaan kijken als alternatief.

BCC schreef op woensdag 06 december 2006 @ 14:23:
Waarom zet je die site dan niet gewoon op HTTPS? Dan wordt alle SSL door Apache / de Browser netjes voor je afgehandeld.

Klopt. En voor dit geval zijn de kosten daarvoor ook nog wel te overzien. Het moet dan wel een signed certificaat zijn, het is voor een grotere groep gebruikers. Maar ik had graag gezien dat ik dit ook anders op kan lossen, want in een volgende situatie is misschien HTTPS/SSL niet mogelijk

Fuzzillogic schreef op woensdag 06 december 2006 @ 22:09:Dat maakt toch niet uit? Die hash is toch ook een "wachtwoord".

(...)

Of eh.. zie ik het nou verkeerd?

Opzich heb je gelijk, ware het niet dat ik de ldap functies een onversleuteld en onverhashd wachtwoord moet aanbieden. Het is naar mijn weten niet mogelijk om met ldap_bind() iets anders dan een plain wachtwoord te gebruiken...

[Cloud]

Priet schreef op donderdag 07 december 2006 @ 13:40:
Klopt. En voor dit geval zijn de kosten daarvoor ook nog wel te overzien. Het moet dan wel een signed certificaat zijn, het is voor een grotere groep gebruikers. Maar ik had graag gezien dat ik dit ook anders op kan lossen, want in een volgende situatie is misschien HTTPS/SSL niet mogelijk

In principe kan ik mij geen situatie voorstellen waarin HTTPS/SSL niet mogelijk is, anders dan qua financiën (hooguit een provider die geen SSL ondersteunt maar dat lijkt mij geen probleem). HTTPS/SSL verzorgt gewoon de overdracht van informatie, die jij gewoon weer plaintext binnen krijgt. Voor zover ik weet verschilt er verder niets met gewoon HTTP.

disclaimer: ik kan er naast zitten natuurlijk

[ Voor 4% gewijzigd door Cloud op 07-12-2006 13:45 . Reden: disclaimer ]

[Verwijderd]

En je hebt natuurlijk ook nog de gratis cert boeren zoals CACert en anderen. Even 1 rootcertificaat installeren op de client (voor alle CACert users heb je het dan meteen gereed), en gaan met de banaan.

Knappe jonge die SSL reversed in die korte tijd.