Even meedenken over versleutelen password
Het enige waar ik steeds tegen aanloop is het wachtwoord en 'the man in the middle' gebeuren die ook gehashde wachtwoorden zou kunnen misbruiken.
Nu had ik het volgende idee:
Wanneer gebruikersnaam en wachtwoord op de inlogpagina moet worden verwerkt gaat deze eerst m.b.v. 'onsubmit' door een functie alwaar een willekeurig gekozen code uit de codesdatabase met het wachtwoord wordt gehasd.
Dezelfde willekeurige code wordt ook meteen bij de gebruikersnaam in de gebruikersdatabase opgeslagen.
Daarna wordt gebruikersnaam en gecodeerde wachtwoord opgestuurd en vergeleken met het wachtwoord en opgeslagen code in de gebruikersdatabase (eerst samen hashen) waarna meteen de opgeslagen code wordt verwijderd. Alles OK dus doorgaan of nieuwe poging starten van voor af aan. Zo wordt er steeds een andere hash verstuurd die maar 1x geldig is.
Lijkt dit wat of kan ik mij schrap gaan zetten voor jullie (opbouwende) kritiek...
Harry
Gewijzigd op 01/01/1970 01:00:00 door Harry
leuke avatar btw (de vrouw dan xD)
Gewijzigd op 01/01/1970 01:00:00 door Onbekend Onbekend
Ja, dat is een leuke virtuele... ;-)
Ik dacht iets van een 30 € per maand voor een certificaat
Maarre... lijkt mijn oplossing/idee wat of zeggen jullie... wow, wat lek!
RedCrew schreef op 27.10.2007 17:23:
Dat kost wel veel geld
Ik dacht iets van een 30 € per maand voor een certificaat
Ik dacht iets van een 30 € per maand voor een certificaat
Mijn server heeft een eigen certificaat, compleet gratis. Hij is ook niet gekocht oid, de server maakt hem zelf aan. Ik kan met vele protocollen verbinden naar de server, incl HTTPS. Enige wat je moet doen is bij bijv firefox even op certificaat permanent accepteren klikken omdat het geen gekocht en dus offcieel certificaat is.
Harry schreef op 27.10.2007 17:37:
Ja, ja, ok, ok, genoeg over de certificaten... ;-)
Maarre... lijkt mijn oplossing/idee wat of zeggen jullie... wow, wat lek!
Maarre... lijkt mijn oplossing/idee wat of zeggen jullie... wow, wat lek!
Het is geen oplossing. https wel.
Arjan Kapteijn schreef op 27.10.2007 18:22:
Het is geen oplossing. https wel.
Harry schreef op 27.10.2007 17:37:
Ja, ja, ok, ok, genoeg over de certificaten... ;-)
Maarre... lijkt mijn oplossing/idee wat of zeggen jullie... wow, wat lek!
Maarre... lijkt mijn oplossing/idee wat of zeggen jullie... wow, wat lek!
Het is geen oplossing. https wel.
Nou, dat is nog eens even opbouwend... bedankt voor het lezen.
Als je namelijk bij het opslaan een Ajax-request doet, loop je het risico dat het afhandelen van die request langer duurt dan het opvragen van de volgende pagina. Dan staat de code dus nog niet in de database.
Helaas, ik denk dat het je niet gaat lukken zo.
Koen Scheres schreef op 27.10.2007 21:03:
of je slaat het wachtwoord op als md5 en zodra je er een cookie ofzo van maakt doe je simpel base64_encode en base64_decode, dat is goed genoeg lijkt mij..
Zeg maar niets als je het probleem niet snapt.
PHP Newbie schreef op 27.10.2007 21:05:
Zeg maar niets als je het probleem niet snapt.
Koen Scheres schreef op 27.10.2007 21:03:
of je slaat het wachtwoord op als md5 en zodra je er een cookie ofzo van maakt doe je simpel base64_encode en base64_decode, dat is goed genoeg lijkt mij..
Zeg maar niets als je het probleem niet snapt.
Sorry las even verkeerd :$
Maar als je echt safe wilt zijn zul je toch echt https moeten gebruiken...
PHP Newbie schreef op 27.10.2007 21:05:
Zeg maar niets als je het probleem niet snapt.
Koen Scheres schreef op 27.10.2007 21:03:
of je slaat het wachtwoord op als md5 en zodra je er een cookie ofzo van maakt doe je simpel base64_encode en base64_decode, dat is goed genoeg lijkt mij..
Zeg maar niets als je het probleem niet snapt.
Inderdaad, het probleem is namelijk dat bij punt 1 al de gegevens kunnen worden onderschept in het onderstaande:
(Uitleg: De stippellijn is de connectie tussen de verschillende elementen)
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
FORM (user)
|
| (1)
|
PHP script => MD5 (server)
|
| (2)
|
Database (server)
|
| (1)
|
PHP script => MD5 (server)
|
| (2)
|
Database (server)
Gewijzigd op 01/01/1970 01:00:00 door GaMer B
Maar ik denk niet dat je je over je wachtwoord zorgen moet gaan maken op dit moment. Als er iemand al op je lijn zit, kan deze hoogstwaarschijnlijk ook gewoon meekijken met de 'geheime' pagina's die jij bezoekt. Ook kan hij gewoon je cookie (en dus je sessie) overnemen.
Als hij zelfs daadwerkelijk tussen jou en de server inzit kan hij ook gewoon het formulier aanpassen. Simpel een kwestie van een ander formulier voorschotelen dat exact hetzelfde eruit ziet, en ik heb je wachtwoord als nog. Phishing wordt dat ook wel genoemd volgens mij. Of ik pas het javascript-gebeuren wat aan zodat deze ook het ongehashde wachtwoord naar mij toestuurt. Niemand die daar iets van merkt.
Oftewel: de enige echte oplossing is een beveiligde verbinding.
Quote:
En wat is het risico dat je loopt? Hoeveel geld gaat het je kosten als iemand een wachtwoord weet te onderscheppen en dit gaat misbruiken. En hoe groot is de kans dat je dit gaat gebeuren?Het enige waar ik steeds tegen aanloop is het wachtwoord en 'the man in the middle' gebeuren die ook gehashde wachtwoorden zou kunnen misbruiken.
Wanneer er een kans van 1 op een miljoen is dat je wellicht 100 euro armer wordt, dan is er dus niks aan de hand.
Is er een kans van 1 op een miljoen dat je hiermee 100 miljoen euro armer wordt, dan is een kleine investering in een SSL-certificaatje van enkele tientjes geen slechte keuze.
Bij minstens 999 van de 1000 inlog-toepassingen is er niks aan de hand wanneer een wachtwoord wordt onderschept, dus niks om je druk over te maken. Ben je die ene uitzondering, dan doe je niet moeilijk over een ssl-certificaatje. Waar hebben we het over! Enkele tientjes per jaar, neem een krantenwijk en dat probleem is ook weer opgelost.