Ideale beveiliging?
Ik zat net wat te speculeren over een waterdichte beveiliging bij het verzenden van (inlog-)data van de bezoeker naar de server mocht je geen SSL tot je beschikking hebben, en kwam tot het volgende idee:
* Je site maakt gebruik van sessies.
* Die sessies zijn IP-gebonden, simpelweg door het IP van de bezoeker bij het aanmaken van de sessie op te slaan in $_SESSION['ip'] en bij iedere reload te controleren. Klopt het IP niet, dan wordt de sessie vernietigd.
* Op het inlogformulier moet je een captcha invullen.
* Het antwoord van de captcha staat - je raad het al - in de IP-gebonden sessie.
* Zodra men het inlogformulier wil verzenden wordt het wachtwoord samen met het ingetypte antwoord van de captcha gehashed. Versleutelen kan d.m.v. eindeloos moeilijke dingen als de AES-versleuteling, maar ook prima met een oude methode als het vigenèrecijfer.
* Het wachtwoord zelf wordt niet verzonden, puur de hash.
* Op de server wordt het wachtwoord samen met de captcha door PHP versleuteld en gehashed, en wordt gechecked met de userinput.
* Klopt dit, dan ben je ingelogd.
Mijn manier om te controleren of iets waterdicht is is door alle dingen die opgevangen kunnen worden door een man in the middle bij langs te gaan, hieronder even uitgeschreven:
* Sessie-cookie: session-hijacking is niet mogelijk door de IP-controle.
* Inlogformulier: staat geen specifieke data op.
* Captcha: is sessie-specifiek, dus ookal kan the man in the middle hem onderscheppen en neemt de moeite om deze met de hand om te zetten naar letters, dan is het alsnog nutteloos.
* Inlogdata: deze is versleuteld d.m.v. de sessie-specifieke captcha en ook nog gehashed, dus ook hier maakt het niet uit.
Dan vraag je je misschien af: waarom zou je een captcha gebruiken, en niet gewoon een waarde die je rechtstreeks meegeeft aan JavaScript?
Zodra the man in the middle al jouw data zou kunnen onderscheppen an tientallen inlogpogingen - wat een kleine kans is, maar elke kans is een kans - zou hij de hashes via een on-line of eigen database met hashes kunnen ontcijferen naar de oorspronkelijke codering. Zodra hij dan ook met alle waardes uit JavaScript gaat bruteforcen, heeft hij het wachtwoord binnen no-time te pakken.
Nu we een captcha gebruiken is dat moeilijker, als je je captcha namelijk een beetje goed maakt kan deze niet automatisch ontcijferd worden, en moet dat dus handmatig gebeuren. Als je het dan nog moeilijker maakt, door bijvoorbeeld je captcha op te bouwen uit plaatjes van 5*5px, in verschillende bestandsformaten, en een deel an de plaatjes meegeeft via base64 codering in de src-tag an de afbeelding, zal de kans klein zijn dat the man in the middle de captcha compleet krijgt, en daarna ook nog de moeite neemt deze te ontcijferen.
Graag jullie reactie op deze theorie!
Mvg,
Jonathan.
PC: de 'v' toets is (half)kapot, dus mogelijk valt er af-en-toe wat weg...
Verder zou ik het simpel kunnen doen, en de inlogpagina aanpassen (of dus deze pagina via mijn proxy spoofen zodat de inlogpagina mijn inlogpagina wordt) zodat deze niet het javascript-gedeelte uitvoert, maar gewoon lekker het ww naar mij toestuurt. Ik kan ook ingewikkelder doen en het captcha-plaatje onderscheppen en mijn eigen opsturen zodat ik dat deel van de hash al weet. De gebruiker zal wel alsmaar de melding krijgen dat z'n ww niet klopt, maar hij zal juist daardoor het meerdere malen proberen. Meer hashes voor mij.
Hiervan afgezien kan ik ook gewoon wachten tot de gebruiker is ingelogd, en de gegevens die ik wil hebben meelezen. Of ik neem de sessie over zodra de gebruiker is ingelogd, zodat ik mij voordoe als de gebruiker.
Het idee van een beveiligde verbinding is niet alleen dat je verkeer niet zomaar uit te lezen is, maar ook dat je zekerheid hebt dat je met de goeie server contact hebt. Dit maakt mijn spoofen, wat ik nodig zou hebben om de pagina's aan te passen, onmogelijk.
Bottom line: ik denk niet dat het de moeite loont zoveel tijd te investeren in javascript encryptie werkend te krijgen en de gebruiker te treiteren met captcha's voor het kleine beetje extra (schijn?)veiligheid dat het oplevert.
edit: dit is overigens ook puur theorie. Ik weet niet hoe een hacker een man-in-the-middle attack zou uitvoeren, ik heb het zelf nog nooit geprobeerd. Als ik het echter zou proberen, zou ik het zo doen.
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
Jelmer schreef op 29.07.2008 20:16:
edit: dit is overigens ook puur theorie. Ik weet niet hoe een hacker een man-in-the-middle attack zou uitvoeren, ik heb het zelf nog nooit geprobeerd. Als ik het echter zou proberen, zou ik het zo doen.
Dat is meestal social engineering. Oftewel eeen JS injection maken zodat de sessie gekaapt kan worden, een proxy op gezet kan worden en noem het maar op.