[AJAX] Client-side security issue

[imp4ct]

Ik zit met het volgende probleem. Zoals je nu wel vaker ziet zijn er veel sites waarbij je een inlog form krijgt dat door jQuery mooi met een fadeIn wordt getoond, achtergrond wordt een overlay over getrokken en het inloggen / registreren verloopt zeer makkelijk.

Wat mijn probleem is, is dat ik wil voorkomen dat de paswoorden volledig zonder hash of iets anders te achterhalen zijn. Bij veel websites zie je gewoon dat bij de ajax.post request het paswoord gewoon zonder enige incryptie wordt meegestuurd.

Ik heb wat liggen zoeken en ervoor zorgen dat ik in een https omgeving zit zou een oplossing zijn, maar deze is voor mij niet haalbaar en er een SHA1 of MD5 hash erover trekken is ook niet een oplossing, want bv. bij het registratie formulier is het nodig dat ik het wachtwoord ongecodeerd binnen krijg, omdat het wachtwoord in de mail nog eens dient vermeld te worden.

Nu is dus mijn vraag of er manier zijn dat je dit toch op een redelijke veilige manier kan oplossen. Dus.. gaande van een login formulier en een registratie formulier, hoe kan je zo goed mogelijk voorkomen dat de info die je naar de server verstuurt en dan met de nadruk op het paswoord niet om nauwelijks onderschept kan worden.

[RobIII]

imp4ct schreef op donderdag 23 september 2010 @ 23:28:
omdat het wachtwoord in de mail nog eens dient vermeld te worden.

Want
Mails raken verdwaald, gekopieerd, virussen sturen ze door, webmailboxes raken gehacked en weet ik het wat. Een wachtwoord in een mail zetten is nog vele malen dommer dan het als plain text over een HTTP verbinding sturen bij inloggen dus daar zit je probleem
En als dat uit de weg is kun je dus lekker met MD5 hashes en andere zaken aan de gang en is heel je probleem opgelost

En waarom is een SSL certificaat niet "haalbaar"? Zo duur is het nou ook weer niet en een certificaatje van een paar tientjes spaart je dan alweer een heleboel devwerk en is uiteindelijk geheid goedkoper

[ Voor 18% gewijzigd door RobIII op 23-09-2010 23:40 ]

[DUX]

Waarom dient het wachtwoord nog eens in de mail getoond te worden? Dat is dan toch ook weer een beveiligingsrisico met veelal onbeveiligde verbindingen? Ik zou het wachtwoord nimmer ongecodeerd opslaan of weergeven ergens, en de bezoeker de mogelijkheid bieden om automatisch een nieuw wachtwoord te laten genereren (met een soort van challenge/response-systeem misschien wel).

Je kunt prima een md5-hash erover heen gooien (vergeet de salt niet) aan de client-kant, als je dat aan de serverkant ook maar doet

edit:
too slow!

[iH8]

Stap inderdaad over op SSL of kijk eens naar een challenge/response javascript oplossing voor clients die echt niet anders kunnen. SSL is per definitie echt je beste oplossing.

[imp4ct]

RobIII schreef op donderdag 23 september 2010 @ 23:31:
[...]

Want
Mails raken verdwaald, gekopieerd, virussen sturen ze door, webmailboxes raken gehacked en weet ik het wat. Een wachtwoord in een mail zetten is nog vele malen dommer dan het als plain text over een HTTP verbinding sturen bij inloggen dus daar zit je probleem
En als dat uit de weg is kun je dus lekker met MD5 hashes en andere zaken aan de gang en is heel je probleem opgelost

En waarom is een SSL certificaat niet "haalbaar"? Zo duur is het nou ook weer niet en een certificaatje van een paar tientjes spaart je dan alweer een heleboel devwerk en is uiteindelijk geheid goedkoper

Wat dat wachtwoord in die mail betreft, heb weinig keuze.. klant wil het nu eenmaal zo. Dat het niet veilig is, mja... daar heb je helemaal gelijk in.

Wat SSL betreft ook hier, klant wilt de investering niet doen en ik zit ook nog wel met een vraagteken, in de zin van... is het de bedoeling dat je ajax.post request naar een https adres word verstuurd, of moet je, je al bevinden in een URL met https voor dat de ajax.post request verstuurd word?

[RobIII]

imp4ct schreef op vrijdag 24 september 2010 @ 00:08:
[...]


Wat dat wachtwoord in die mail betreft, heb weinig keuze.. klant wil het nu eenmaal zo. Dat het niet veilig is, mja... daar heb je helemaal gelijk in.

En, goede developer als je bent, jij licht dan je klant daar weer over in en school je 'm bij waar nodig en hamert net zo lang tot 'ie deze onzin requirement laat varen Je moet 'm gewoon even subtiel vertellen dat 't kul is (én onnodig at that).

imp4ct schreef op vrijdag 24 september 2010 @ 00:08:
Wat SSL betreft ook hier, klant wilt de investering niet doen

Poehee, €12 per jaar, da's €1 per maand. Talk about voor een duppie op de eerste rang willen zitten Wat kost de website die je voor 'm aan 't bouwen bent dan? Ik denk dat je klant eens even z'n bril goed op moet zetten, want iets klopt hier niet

imp4ct schreef op vrijdag 24 september 2010 @ 00:08:
is het de bedoeling dat je ajax.post request naar een https adres word verstuurd

Euh, natuurlijk. Maar behalve een extra s in de url merk je daar niets van hoor Doet geen pijn ofzo

imp4ct schreef op vrijdag 24 september 2010 @ 00:08:
of moet je, je al bevinden in een URL met https voor dat de ajax.post request verstuurd word?

Naar een HTTPS pagina gaat altijd; ongeacht of je op een HTTP of HTTPS pagina zit. Zit je op een HTTPS pagina dan kun je niet zomaar naar een gewone HTTP pagina posten zonder tegen vervelende meldingen e.d. aan te lopen. Maar waarom zou je dat überhaupt nog willen?

Let wel even op dat SSL niet met "VHosts" overweg kan trouwens!

[ Voor 66% gewijzigd door RobIII op 24-09-2010 00:24 ]

[imp4ct]

Zeer goeie tips! Duidelijk advies... thx!!

[.oisyn]

RobIII schreef op vrijdag 24 september 2010 @ 00:14:
Let wel even op dat SSL niet met "VHosts" overweg kan trouwens!

't Kan wel, alleen moeten alle vhosts een enkel certificaat sharen.

[johnkeates]

RobIII schreef op vrijdag 24 september 2010 @ 00:14:
[...]
Let wel even op dat SSL niet met "VHosts" overweg kan trouwens!

Dat kan zeker wel, en je kan zelfs meerdere SSL vhosts op 1 IP/instance draaien, een eis is dat je dan wel de certkeys door apache laat lezen, of bij opstarten doorgeeft.

Als de keys geen optie zijn, bijv. als het onveilig geacht wordt (stel dat er meerdere mensen toegang hebben tot de server en de keys kunnen stelen e.d.), dan is 1 SSL vhost ook nog makkelijk mogelijk. De rest van de vhosts op hetzelfde IP moeten dan wel non-SSL zijn natuurlijk.


On topic: je kan RSA gebruiken. Er zijn vast wel implementaties te vinden, het zal niet snel zijn, maar het is met de huidige stand van zaken niet 'kraakbaar' (behalve als je data meer dan 10 jaar 100% gegarandeerd veilig moet zijn (en geen lang key wil) - maar dan heb je ook nog het user probleem; gebruikers hebben graag makkelijke wachtwoorden).

[RobIII]

.oisyn schreef op vrijdag 24 september 2010 @ 00:31:
[...]

't Kan wel, alleen moeten alle vhosts een enkel certificaat sharen.

Ja, maar die zijn een stuk duurder
Verder leek 't stukje waar ik naar linkte me wel duidelijk uit te leggen "dat het wel kan" maar niet zonder mitsen en maren.

[ Voor 21% gewijzigd door RobIII op 24-09-2010 00:45 ]

[imp4ct]

Waarschijnlijk een domme vraag, maar goed.. Ik weet wat de functie van een salt is enz.. Maar als je deze gaat gebruiken in de front-end dan is hij toch zowiezo ook gekend. En als je hem pas gaat gebruiken nadat de ajax.post request is verstuurd en je dus in de PHP functie ben aan't werken, dan is het toch een verloren moeite niet?

Misschien kan iemand een simpel voorbeeld geven, want ik zit er wat mee in de knoop hoe dat nu juist aan te pakken.

[RobIII]

You Want Salt With That? Part One: Security vs Obscurity
You Want Salt With That? Part Two: We Need A Hash
You Want Salt With That? Part Three: Salt The Hash
You Want Salt With That? Part Four: Challenge-Response

En wat had je zelf al gevonden na een beetje googlen? Want het is echt geen rocket science ofzo...

[ Voor 28% gewijzigd door RobIII op 24-09-2010 09:44 ]

[imp4ct]

RobIII schreef op vrijdag 24 september 2010 @ 09:43:
En wat had je zelf al gevonden na een beetje googlen? Want het is echt geen rocket science ofzo...

Niet die artikels allesinds, meer bij PHPHulp en wat jQuery security topics, maar vond ze niet echt duidelijk genoeg voor het probleem waarmee ik zat.

Edit:
De 4 blogposts gelezen, zijn erg goed! Thx.. nu een degelijk systeem opzetten

[ Voor 11% gewijzigd door imp4ct op 24-09-2010 10:44 ]