Secure Login en Zoeken

[Verwijderd]

Komt er binnenkort (of misschien is het ergens al...) nog de mogelijkheid om 'secure' (bv via https) in te loggen? Met het steeds groeiende aantal WiFi hotspots (en dus in beginsel untrusted networks) waar ik steeds vaker gebruik van maak met mijn laptop, vind ik het geen prettig idee om 'clear text' users/pass over te sturen (wel om te surfen e.d.).

Tweede vraag: [snip: Je hebt gelijk, Dark_Rain, het was me nog niet eens opgevallen.. t0f ! ]

[ Voor 54% gewijzigd door Verwijderd op 24-02-2004 11:56 ]

[darkrain]

Voor de tweede vraag kun je toch de quicksearch met Dit forum gebruiken?

[Verwijderd]

(quote ipv edit)

[ Voor 97% gewijzigd door Verwijderd op 24-02-2004 11:56 ]

[We Are Borg]

Dit is al eerder gevraagd Ik kan zelf helaas het topic niet meer vinden, maar misschien iemand met betere search skills wel

[Erkens]

We Are Borg schreef op 24 februari 2004 @ 12:12:
Dit is al eerder gevraagd Ik kan zelf helaas het topic niet meer vinden, maar misschien iemand met betere search skills wel

dank

Secure login

[Spider.007]

Oftewel:

In React 1.9 zou het erin moeten zitten (MD5 encryptie aan clientkant dus)

[ Voor 26% gewijzigd door Spider.007 op 24-02-2004 14:48 ]

[We Are Borg]

Erkens schreef op 24 februari 2004 @ 12:19:
[...]

dank

Secure login

Wat doet dat topic nu weer in LA ?

[decramy]

Het zit dus in 1.9, maar ik merk er niets van?

Hoe ik denk dat het best veilig in elkaar zit:
Client MD5t w8w00rd
Client verstuurt MD5t w8w00rd
MD5t w8w00rd kan evt opgevangen worden
Server MD5t MD5hash
Server controleert

In de database staat dus eigenlijk MD5(MD5($password))

Veilig??

[crisp]

client-side een WW MD5-en heeft weinig zin als je daarbij geen gebruik maakt van een challenge die je in die MD5 verwerkt lijkt me...

[chem]

crisp de md5 is een md5 van reactid+pass+userid.

[crisp]

chem schreef op 26 februari 2004 @ 12:40:
crisp de md5 is een md5 van reactid+pass+userid.

ik had ook niet anders verwacht eigenlijk

[crisp]

misschien eens onderzoeken voor GoT

[Osiris]

Volgens Kees in [rml][ Feature] Beveiligde login (SSL?)[/rml] staat een SSL-verbinding met GoT op de ToDo, dus dat zal al een boel schelen Wachtwoorden via een SSL-tunnel hoeven dan niet ge-md5-ed te worden lijkt me

[crisp]

tsja, op zich lijkt het me niet zo moeilijk om die md5 hashing met een optie in te bouwen, maar ik mis daarover de documentatie van Parse, en in base_grey zit het niet

[chem]

crisp, je moet een data[passwordencryption] = 'md5join' meegeven, en data[password] is dan md(Password.$username.$reactid) (dus met JS het veld aanpassen).

[crisp]

a, nice; lijkt me niet zo moeilijk om in te bouwen met een tickboxje 'versleutel mijn wachtwoord'

[crisp]

chem: ik neem aan dat ik hex_md5 moet hebben, maar met hex_md5(pwd+uname+reactid) krijg ik "encrypted password not correct for user"

[Spider.007]

Het overschrijven van het password field met de md5 waarde van pwd+uname+reactId heeft wel als nadeel dat eventuele password managers niet meer zullen werken op GoT tenzij het reactId statisch wordt. Dit is tegelijkertijd niet te omzeilen omdat het hele punt van deze beveiliging juist is dat er niet telkens met dezelfde gegevens is in te loggen. Of is hier een aanpassing in te maken?

[justmental]

Het wachtwoord versleutelen heeft natuurlijk nog niet heel veel zin omdat het reactid gewoon met elk request mee komt.

[Spider.007]

justmental schreef op 22 juli 2004 @ 09:19:
Het wachtwoord versleutelen heeft natuurlijk nog niet heel veel zin omdat het reactid gewoon met elk request mee komt.

Het zou inderdaad veiliger zijn om hier een md5hash van een (timestamp in minuten+keyphrase) mee te sturen ipv het reactId. Tegelijkertijd krijg je bij iedere hernieuwde inlogpoging een nieuw reactId en is je vorige md5hash dus niet meer te gebruiken

[chem]

crisp schreef op 22 juli 2004 @ 08:16:
chem: ik neem aan dat ik hex_md5 moet hebben, maar met hex_md5(pwd+uname+reactid) krijg ik "encrypted password not correct for user"

Wat ik ooit gebouwd heb was...

HTML:

onSubmit="if(md5_vm_test()) {document.getElementById('pwd').value = hex_md5(hex_md5(document.getElementById('pwd').value) + document.getElementById('username').value + '{board_reactid}'); document.getElementById('pwdenc').value='md5join'; }"

[crisp]

ah, dus md5( md5(pwd) + uname + reactid )

justmental schreef op 22 juli 2004 @ 09:19:
Het wachtwoord versleutelen heeft natuurlijk nog niet heel veel zin omdat het reactid gewoon met elk request mee komt.

Het is ook geen perfect mechanisme, dan zou je een eenmalige challenge moeten gebruiken en die meehashen (reactid is statisch voor een sessie), maar het is in ieder geval al wel een stukje veiliger. Zelfs al zou je de hash opvangen moet je ook nog een sessie kapen, en je kan niet zomaar het wachtwoord achterhalen.

Spider.007 schreef op 22 juli 2004 @ 09:27:
[...]

Het zou inderdaad veiliger zijn om hier een md5hash van een (timestamp in minuten+keyphrase) mee te sturen ipv het reactId. Tegelijkertijd krijg je bij iedere hernieuwde inlogpoging een nieuw reactId en is je vorige md5hash dus niet meer te gebruiken

Ik heb het nooit geverifieerd of je na iedere inlogpoging een nieuw reactid krijgt, maar dat zou best kunnen. In dat geval is de opgevangen hash natuurlijk waardeloos, en is het mechanisme naar mijn mening best wel veilig.

Spider.007 schreef op 22 juli 2004 @ 09:15:
Het overschrijven van het password field met de md5 waarde van pwd+uname+reactId heeft wel als nadeel dat eventuele password managers niet meer zullen werken op GoT tenzij het reactId statisch wordt. Dit is tegelijkertijd niet te omzeilen omdat het hele punt van deze beveiliging juist is dat er niet telkens met dezelfde gegevens is in te loggen. Of is hier een aanpassing in te maken?

Als je bezorgt bent om je veiligheid gebruik je waarschijnlijk geen passwordmanager
In ieder geval is het een optionele feature; je moet een vinkje zetten op de login pagina om het te activeren

[ Voor 140% gewijzigd door crisp op 22-07-2004 11:09 ]

[crisp]

werkt! \o/