Security zwakheden Tweakers?

[Verwijderd]

Zag een leuke twitter 'conversatie' staan tussen jullie collega J. Schellevis en iemand die
ik volg op Twitter (R. Gevers). Nu zie ik dus net een blog van laatstgenoemde getwitterd
worden en ben ik gaan lezen (geen reclame / promotie nee) en zie ik toch aardig interessante
puntjes betreffende de security op Tweakers.net.

http://twitter.com/#!/RickeyGevers/status/106770944005128192
https://twitter.com/#!/Schellevis/status/107129603675533312

Kan dit nog ontkracht worden?

Blog

[DexterDee]

Dit topic is meer iets voor Lieve Devvers dan Lieve Adjes denk ik

[DennusB]

Interessant om te lezen Ben benieuwd wat Tweakers hier mee doet. Wel weet ik dat de MD5 strings al verleden tijd zijn sinds vandaag(toch?). Dus dat is alvast goed

[TrailBlazer]

dat de wachtwoorden van tweakers open en bloot over het net gaan was toch al jaren bekend. Verder klinkt het heel erg stoer dat sniffen maar zo eenvoudig is het niet om even een wachtwoord te sniffen. Het is ook geen bankapplicatie.

[DennusB]

TrailBlazer schreef op maandag 29 augustus 2011 @ 15:24:
dat de wachtwoorden van tweakers open en bloot over het net gaan was toch al jaren bekend. Verder klinkt het heel erg stoer dat sniffen maar zo eenvoudig is het niet om even een wachtwoord te sniffen. Het is ook geen bankapplicatie.

Niet eenvoudig? Ik download thuis of op werk wireshark, m'n broertje/zusje/neefje/collega/sinterklaas logt in en hoppa. Wachtwoord te pakken.
Eenvoudiger kan haast niet toch?

[DinX]

DennusB schreef op maandag 29 augustus 2011 @ 15:26:
[...]


Niet eenvoudig? Ik download thuis of op werk wireshark, m'n broertje/zusje/neefje/collega/sinterklaas logt in en hoppa. Wachtwoord te pakken.
Eenvoudiger kan haast niet toch?

Veel succes als je allemaal op een gewone switch hangt om iets te sniffen van die andere computer.

[TrailBlazer]

ja alleen als er iemand thuis in kan loggen zou ik me zorgen maken over iets anders. Dan kan je net zo goed een keylogger installeren en ben je net zo ver met je 256 bits geencrypte HTTPS verbinding.

[ Voor 40% gewijzigd door TrailBlazer op 29-08-2011 15:28 ]

[Gardocki]

DinX schreef op maandag 29 augustus 2011 @ 15:27:
[...]


Veel succes als je allemaal op een gewone switch hangt om iets te sniffen van die andere computer.

Vrij eenvoudig met een man-in-the-middle attack, m.b.v. ARP spoofing oid.

[Verwijderd]

DennusB schreef op maandag 29 augustus 2011 @ 15:26:
[...]


Niet eenvoudig? Ik download thuis of op werk wireshark, m'n broertje/zusje/neefje/collega/sinterklaas logt in en hoppa. Wachtwoord te pakken.
Eenvoudiger kan haast niet toch?

keylogger
het is maar net wat je hacken noemt

[dcm360]

DennusB schreef op maandag 29 augustus 2011 @ 15:26:
[...]


Niet eenvoudig? Ik download thuis of op werk wireshark, m'n broertje/zusje/neefje/collega/sinterklaas logt in en hoppa. Wachtwoord te pakken.
Eenvoudiger kan haast niet toch?

Op dat moment is de beveiliging lokaal op de PC gewoon stuk.

Overigens vind ik dat er in die blog een paar rare aannames gemaakt worden. Ja, het wachtwoord wordt met MD5 gecodeerd verstuurd. Conclusie van de schrijver: de wachtwoorden worden met alleen MD5 opgeslagen in de database. Ehm, wut?

[DexterDee]

DennusB schreef op maandag 29 augustus 2011 @ 15:26:
[...]

Niet eenvoudig? Ik download thuis of op werk wireshark, m'n broertje/zusje/neefje/collega/sinterklaas logt in en hoppa. Wachtwoord te pakken.
Eenvoudiger kan haast niet toch?

Dat is tegenwoordig lang niet altijd meer triviaal. Vroeger met hubs werd al het netwerkverkeer op alle poorten gerepliceerd. Tegenwoordig zoals DinX al aangeeft, stuurt een switch geen netwerkverkeer van andere poorten naar de poort van je eigen computer. Een wireless sniffer behoort nog tot de opties en anders zul je op de router moeten inbreken om daar een tcpdump te maken.

[TrailBlazer]

en als mensen dat kunnen doen bij jou thuis of in het DC dan ben je sowieso al te laat om je daar druk over te gaan maken.

[Kain_niaK]

Het hele punt waar het omgaan is dat hoe sterk een beveiliging ook is:
Als jou lokale beveiliging doorbroken word maakt het allemaal niks meer uit.
Ik kan zo op een onbeveiligd draadloos netwerk inloggen.
Vervolgens met een tooltje als Cain aan ARP poisen doen.
Ik kan dan ook aan DNS spoofing doen.
Ik draai local een webserver met een nagemaakte tweakers.net pagina.
En spoof het ip adres van tweakers.net de volgende keer dat er een DNS aanvraag voor komt.
Het slachtoffer komt dan op mijn site terecht en niet op tweakers.net

Daarna heb je het pw natuurlijk te pakken zodra de persoon probeert in te loggen.

Ook kun je cookies sniffen zelfs over https met SSLstripper.
Daarna is inloggen op facebook of gmail niet eens meer nodig.
Zodra de persoon is ingelogt kun jij er ook aan omdat je dezelfde cookies hebt (en het zelfde externe ip adres)

Ik zie hier allemaal geen zwakte in van tweakers.net.
Alleen maar zwakte van lokale slecht beveiligde netwerken.

[Gardocki]

Kain_niaK schreef op maandag 29 augustus 2011 @ 15:44:
Ik zie hier allemaal geen zwakte in van tweakers.net.
Alleen maar zwakte van lokale slecht beveiligde netwerken.

Je credentials over een beveiligde verbinding laten gaan verhoogd de drempel natuurlijk wel aanzienlijk.
Voor de rest ben ik het volledig met je eens.

[TrailBlazer]

ik zeg ook niet dat het niet beter kan. Dit klinkt alleen een beetje alsof iemand die bij zijn eerste college wireshark heeft leren kennen en denkt dat hij een enorm gat heeft gevonden op een techsite.

[CyBeR]

DexterDee schreef op maandag 29 augustus 2011 @ 15:31:
[...]

Dat is tegenwoordig lang niet altijd meer triviaal. Vroeger met hubs werd al het netwerkverkeer op alle poorten gerepliceerd. Tegenwoordig zoals DinX al aangeeft, stuurt een switch geen netwerkverkeer van andere poorten naar de poort van je eigen computer.

Leuk, maar die aanval is nog altijd vrij triviaal. Hij is wel te stoppen hoor maar dan heb je 't niet over huis-tuin-en-keukenswitches.

[ValHallASW]

dcm360 schreef op maandag 29 augustus 2011 @ 15:29:
Overigens vind ik dat er in die blog een paar rare aannames gemaakt worden. Ja, het wachtwoord wordt met MD5 gecodeerd verstuurd. Conclusie van de schrijver: de wachtwoorden worden met alleen MD5 opgeslagen in de database. Ehm, wut?

Elementary, my dear Watson! ;-)

1. md5(a) => b, vanuit b kan je a niet gemakkelijk bepalen
2. het inloggen gebeurt mbv md5(md5(pwd) + uid + sid).
3. sid is een waarde die iedere keer anders is ('nonce')

hieruit volgt dat de server niet md5(md5(pwd) + uid + sid) opgeslagen kan hebben. De server moet derhalve toegang hebben tot de losse onderdelen daarvan:

md5(pwd), uid, sid

Dat de server toegang heeft tot uid en sid is niet gek, maar de server moet dus óók toegang hebben tot md5(pwd), en zoals wij allen weten zijn er genoeg md5-rainbowtables in omloop om daar ongelukkig van te worden.

(ik hoop dat mijn uitleg een beetje duidelijk is; zo niet, roep vooral, dan zal ik proberen het te verduidelijken)

[ Voor 6% gewijzigd door ValHallASW op 29-08-2011 17:19 ]

[DexterDee]

CyBeR schreef op maandag 29 augustus 2011 @ 17:05:
Leuk, maar die aanval is nog altijd vrij triviaal. Hij is wel te stoppen hoor maar dan heb je 't niet over huis-tuin-en-keukenswitches.

Verklaar u nader... want "vrij triviaal" is onderhevig aan iemands referentiekader. Als ik mijn laptop aan een goedkope unmanaged switch hangt, hoe kan ik de packets dan sniffen van mijn buurman die op het volgende poortje op de switch zit?

[dcm360]

ValHallASW schreef op maandag 29 augustus 2011 @ 17:19:
[...]

Elementary, my dear Watson! ;-)

1. md5(a) => b, vanuit b kan je a niet gemakkelijk bepalen
2. het inloggen gebeurt mbv md5(md5(pwd) + uid + sid).
3. sid is een waarde die iedere keer anders is ('nonce')

hieruit volgt dat de server niet md5(md5(pwd) + uid + sid) opgeslagen kan hebben. De server moet derhalve toegang hebben tot de losse onderdelen daarvan:

md5(pwd), uid, sid

Dat de server toegang heeft tot uid en sid is niet gek, maar de server moet dus óók toegang hebben tot md5(pwd), en zoals wij allen weten zijn er genoeg md5-rainbowtables in omloop om daar ongelukkig van te worden.

(ik hoop dat mijn uitleg een beetje duidelijk is; zo niet, roep vooral, dan zal ik proberen het te verduidelijken)

Hm, ik zat dus echt te slapen toen ik dat schreef... Overigens begint het ook steeds meer mogelijk te worden om een bruteforece op md5-hashes toe te passen, met GPGPU op mn laptop is in niet al te veel tijd al redelijk ver te komen.

[TrailBlazer]

DexterDee schreef op maandag 29 augustus 2011 @ 17:32:
[...]

Verklaar u nader... want "vrij triviaal" is onderhevig aan iemands referentiekader. Als ik mijn laptop aan een goedkope unmanaged switch hangt, hoe kan ik de packets dan sniffen van mijn buurman die op het volgende poortje op de switch zit?

je PC doet een arp reply voor het ip adres van de default gateway met zijn mac address. De buurman stuurt nu verkeer met als bestemming de default gateway naar jouw mac adres. Vervolgens kan je dan al het verkeer wat je buurman stuurt bekijken.

[alex3305]

Zoals ik het altijd doe is het volgende:

code:

$password = input["password"];
$salt = "Een lange string met tekens."

$savedPassword = encrypt1(encrypt2($password + $salt));

Waarbij encrypt1 een ander soort encryptie is dan encrypt2. Wanneer je dan wilt weten of een gebruiker toegang mag krijgen tot de site, kies ik ervoor om het vervolgens weer te herhalen en te controleren tegen de database-entry.

Wanneer een kwaadwillende gebruiker dan toegang krijgt tot de database kan hij alleen flinke stukken hashes zien, maar geen manier om het gemakkelijk te ontrafelen.

Als laatste zou je er ook nog voor kunnen kiezen om één encryptie alvast in javascript client-side af te handelen voordat het verstuurd wordt naar de client. Zo maak je het ook moeilijker voor man-in-the-middle attacks.

[mrFoce]

alex3305 schreef op maandag 29 augustus 2011 @ 17:46:
Zoals ik het altijd doe is het volgende:

code:

$password = input["password"];
$salt = "Een lange string met tekens."

$savedPassword = encrypt1(encrypt2($password + $salt));

Waarbij encrypt1 een ander soort encryptie is dan encrypt2. Wanneer je dan wilt weten of een gebruiker toegang mag krijgen tot de site, kies ik ervoor om het vervolgens weer te herhalen en te controleren tegen de database-entry.

Wanneer een kwaadwillende gebruiker dan toegang krijgt tot de database kan hij alleen flinke stukken hashes zien, maar geen manier om het gemakkelijk te ontrafelen.

Als laatste zou je er ook nog voor kunnen kiezen om één encryptie alvast in javascript client-side af te handelen voordat het verstuurd wordt naar de client. Zo maak je het ook moeilijker voor man-in-the-middle attacks.

In principe zou je niet een ander soort encryptie hoeven te gebruiken. Hoe ik het gemaakt heb bij enkele (grote) e-commerce sites komt neer op ongeveer hetzelfde als jij doet. Een salt en SHA-1 encryptie waarbij de encryptie sleutel eigenlijk het wachtwoord van de user zelf is + de salt. Voor de webshop eigenaar kan dit niet 'decrypted' worden, enkel gereset naar een 8+ karakter random wachtwoord..

[Osiris]

dcm360 schreef op maandag 29 augustus 2011 @ 15:29:
[...]

Overigens vind ik dat er in die blog een paar rare aannames gemaakt worden. Ja, het wachtwoord wordt met MD5 gecodeerd verstuurd. Conclusie van de schrijver: de wachtwoorden worden met alleen MD5 opgeslagen in de database. Ehm, wut?

Indien de browser het pwd hasht d.m.v. MD5 en daar vervolgens nog verder wat mee doet, maar T.net heeft bijv een SHA512-hash in de DB staan, tja, dan wordt 't toch lastig om die twee met elkaar te vergelijken dunkt me.

Ik snap sowieso niet waarom ik nooit een Wikipedia: Diffie–Hellman key exchange in 't wild tegenkom. Al dat gezeik met hashes en shit. Google heeft d'r aardig wat resultaten over, Diffie-Hellman i.c.m. Javascript.

[ Voor 20% gewijzigd door Osiris op 29-08-2011 18:00 ]

[dcm360]

Osiris schreef op maandag 29 augustus 2011 @ 17:56:
[...]

Indien de browser het pwd hasht d.m.v. MD5 en daar vervolgens nog verder wat mee doet, maar T.net heeft bijv een SHA512-hash in de DB staan, tja, dan wordt 't toch lastig om die twee met elkaar te vergelijken dunkt me.

Ik snap sowieso niet waarom ik nooit een Wikipedia: Diffie–Hellman key exchange in 't wild tegenkom. Al dat gezeik met hashes en shit. Google heeft d'r aardig wat resultaten over, Diffie-Hellman i.c.m. Javascript.

Zie mn vorige reactie...

[DexterDee]

TrailBlazer schreef op maandag 29 augustus 2011 @ 17:44:
[...]

je PC doet een arp reply voor het ip adres van de default gateway met zijn mac address. De buurman stuurt nu verkeer met als bestemming de default gateway naar jouw mac adres. Vervolgens kan je dan al het verkeer wat je buurman stuurt bekijken.

Bedankt voor de uitleg.

Echt heel triviaal vind ik het niet, aangezien ARP requests gecached worden. Als de buurman zijn PC al aan heeft staan, staat het MAC adres van de gateway al in z'n cache. Ik weet niet wat de TTL van die cache is, maar het lijkt me dat je die moet uitzitten. Daarna moet je ook nog eens sneller dan de router een ARP reply geven. En als het lukt, zul je het verkeer van de buurman ook nog moet forwarden naar de echte gateway. Anders heeft de buurman geen internet connectiviteit en is het snel uit met de pret.

[CoolGamer]

Alles wat via HTTP loopt i.p.v. HTTPS kan worden onderschept d.m.v. een man-in-the-middle. In de tweet wordt gezegd dat je kan inloggen via SSL, maar dat heb ik niet kunnen vinden. Ook als er gebruik wordt gemaakt encryptie in javascript kan het wachtwoord in theorie worden onderschept (de man-in-the-middle kan de encryptie weghalen). Een man-in-the-middle-aanval opzetten is op sommige netwerken lastiger dan andere. Op een onbeveiligd netwerk is het niet moeilijk, maar op een goed beveiligd bedrijfsnetwerk worden zulk soort dingen automatisch opgemerkt worden. Er zijn ook firewalls die ARP-attacks kunnen detecteren.

Zo'n valse ARP-update wordt continu gestuurd, waarbij een verzoek van de client op een update niet vereist is. Zodra er een update is wordt de cache overschreven.

[ValHallASW]

DexterDee schreef op maandag 29 augustus 2011 @ 18:01:
Echt heel triviaal vind ik het niet, aangezien ARP requests gecached worden. (...) Daarna moet je ook nog eens sneller dan de router een ARP reply geven.

Ware het niet dat je ARP cache geupdatet wordt op het moment dat er een ARP reply binnen komt, óók als er niet daarvoor een ARP request verstuurd is.

[Osiris]

TheCoolGamer schreef op maandag 29 augustus 2011 @ 18:12:
Ook als er gebruik wordt gemaakt encryptie in javascript kan het wachtwoord in theorie worden onderschept (de man-in-the-middle kan de encryptie weghalen).

Wut? Dat mag je w.m.b. nader uitleggen

[CyBeR]

DexterDee schreef op maandag 29 augustus 2011 @ 17:32:
[...]

Verklaar u nader... want "vrij triviaal" is onderhevig aan iemands referentiekader. Als ik mijn laptop aan een goedkope unmanaged switch hangt, hoe kan ik de packets dan sniffen van mijn buurman die op het volgende poortje op de switch zit?

Daar zijn twee simpele methoden voor:

• Het al eerder genoemde ARP cache-poisoning. Je stuurt valse ARPs en daardoor stuurt jouw buurman zijn packets naar jou ipv naar de router (of wat je ook wilt.)
• MAC-tabel flooding. De meeste switches voor thuis hebben een heel simpele logica aangaande hun MAC-adress tabel: als die vol zit, wordt alles wat onbekend is geflood (uit alle poorten) totdat een van de entries expiret. Die switches hebben vervolgens ook nog maar een tabel van meestal 4 of 8 duizend entries, dus dat zit zo vol. Hiermee maak je van je mooie switch in essentie een hub.


Duurdere switches hebben sowieso al grotere tabellen en een betere afhandeling van wat er gebeurt als 'ie dan toch vol komt te zitten, en sommige switches kunnen ook ARPs inspecteren en besluiten of die wel of niet geforward kan worden. Dat kan met een handmatige tabel in de switch, of de switch kan ook DHCP snoopen en aan de hand daarvan een tabel maken van welk IP-adres door welke poort geARPt mag worden.

Osiris schreef op maandag 29 augustus 2011 @ 18:18:
[...]

Wut? Dat mag je w.m.b. nader uitleggen

Aannemelijkerwijs door een eigen javascript te injecteren.

[ Voor 7% gewijzigd door CyBeR op 29-08-2011 18:22 ]

[CoolGamer]

Osiris schreef op maandag 29 augustus 2011 @ 18:18:
[...]

Wut? Dat mag je w.m.b. nader uitleggen

De man-in-the-middle (M) is ook in staat om de inhoud aan te passen. Zo kan M het encryptscript verwijderen of aanpassen. Wanneer de client de pagina submit wordt het wachtwoord niet gecodeerd naar M gestuurd. M kan dan het wachtwoord lezen en dan het wachtwoord eventueel gecodeerd doorsturen naar de oorspronkelijk bedoelde server zodat zowel de server als de client niks merken van de aanval.

[Osiris]

CyBeR schreef op maandag 29 augustus 2011 @ 18:22:
[...]

Aannemelijkerwijs door een eigen javascript te injecteren.

TheCoolGamer schreef op maandag 29 augustus 2011 @ 18:24:
[...]

De man-in-the-middle (M) is ook in staat om de inhoud aan te passen. Zo kan M het encryptscript verwijderen of aanpassen. Wanneer de client de pagina submit wordt het wachtwoord niet gecodeerd naar M gestuurd. M kan dan het wachtwoord lezen en dan het wachtwoord eventueel gecodeerd doorsturen naar de oorspronkelijk bedoelde server zodat zowel de server als de client niks merken van de aanval.

Maar de client is in principe/theorie wel in de mogelijkheid op de hoogte hiervan te zijn, aangezien de geinjecteerde javascript in principe/theorie in de bron van de pagina terug te vinden is. Dus echt 100% stealthy MITM-attack is 't nou ook weer niet.

[RayNbow]

Gerelateerd aan deze discussie? Javascript Cryptography Considered Harmful

[DexterDee]

CyBeR schreef op maandag 29 augustus 2011 @ 18:22:
[...]

Daar zijn twee simpele methoden voor:
[...]

Okay, MAC tabel flooding is dan wel weer dermate simpel dat ik het triviaal zou noemen. Weer wat bijgeleerd.
Bedankt

[RayNbow]

Osiris schreef op maandag 29 augustus 2011 @ 18:29:
[...]


[...]

Maar de client is in principe/theorie wel in de mogelijkheid op de hoogte hiervan te zijn, aangezien de geinjecteerde javascript in principe/theorie in de bron van de pagina terug te vinden is. Dus echt 100% stealthy MITM-attack is 't nou ook weer niet.

Hoe moet een client achterhalen of een geinjecteerd script geinjecteerd is?

[CyBeR]

Osiris schreef op maandag 29 augustus 2011 @ 18:29:
[...]


[...]

Maar de client is in principe/theorie wel in de mogelijkheid op de hoogte hiervan te zijn, aangezien de geinjecteerde javascript in principe/theorie in de bron van de pagina terug te vinden is. Dus echt 100% stealthy MITM-attack is 't nou ook weer niet.

Lees jij voor elke website die je bezoekt de source door? Kun jij vervolgens het verschil zien tussen een echt script en een geinjecteerd script? Bedenk je wel, als je scripts kun injecteren kun je het ook laten lijken alsof je geinjecteerde scripts vanuit de bron die je tracht te bezoeken komen.

[_JGC_]

DexterDee schreef op maandag 29 augustus 2011 @ 18:01:
[...]

Bedankt voor de uitleg.

Echt heel triviaal vind ik het niet, aangezien ARP requests gecached worden. Als de buurman zijn PC al aan heeft staan, staat het MAC adres van de gateway al in z'n cache. Ik weet niet wat de TTL van die cache is, maar het lijkt me dat je die moet uitzitten. Daarna moet je ook nog eens sneller dan de router een ARP reply geven. En als het lukt, zul je het verkeer van de buurman ook nog moet forwarden naar de echte gateway. Anders heeft de buurman geen internet connectiviteit en is het snel uit met de pret.

Nog steeds triviaal. Je hebt vast wel eens iets gezien van duurdere switches dat je verkeer van bepaalde poorten kunt klonen naar een andere poort, zodat je dat verkeer kunt onderzoeken. De rest van het netwerk merkt helemaal niks van dat alles.
Natuurlijk heeft een goedkope switch die optie niet, maar je kunt wel gebruikmaken van de zwakheid van een goedkope switch: ARP table. Je switch houdt van elke poort bij welke MAC adressen op welke poort zitten. Als een adres niet in die tabel staat, stuurt de switch het packet naar alle poorten, in de hoop dat ergens op een van die poorten wel een apparaat zit die dat packet wil hebben. Als je nu gewoon die switch bestookt met random MAC-adressen, zal die tabel overlopen en verandert je goedkope unmanaged switch ineens in een ordinaire hub en komt een groot deel van het verkeer alsnog bij jou aan.

Wat betreft het veilig hashen: een sha1 hash van een md5 hash trekken is helemaal niks veiliger. Ten eerste zijn er rainbow tables voor vanalles en nog wat, maar ten tweede limiteer je de dataset die je in je SHA1 functie stopt tot 32 hexadecimale tekens, wat een stuk makkelijker is dan een input van willekeurige lengte met willekeurige tekens.

[CyBeR]

_JGC_ schreef op maandag 29 augustus 2011 @ 18:38:
[...]

Nog steeds triviaal. Je hebt vast wel eens iets gezien van duurdere switches dat je verkeer van bepaalde poorten kunt klonen naar een andere poort, zodat je dat verkeer kunt onderzoeken. De rest van het netwerk merkt helemaal niks van dat alles.

Gut ja, mirroring kan natuurlijk ook maar dat is dan weer iets dat je als gewone aanvaller als 't goed is niet kunt. Als je dat kunt ben je als 't goed is de netadmin en dan kun je ook gewoon verkeer sniffen op de router zelf natuurlijk

Natuurlijk heeft een goedkope switch die optie niet, maar je kunt wel gebruikmaken van de zwakheid van een goedkope switch: ARP table. Je switch houdt van elke poort bij welke MAC adressen op welke poort zitten. Als een adres niet in die tabel staat, stuurt de switch het packet naar alle poorten, in de hoop dat ergens op een van die poorten wel een apparaat zit die dat packet wil hebben. Als je nu gewoon die switch bestookt met random MAC-adressen, zal die tabel overlopen en verandert je goedkope unmanaged switch ineens in een ordinaire hub en komt een groot deel van het verkeer alsnog bij jou aan.

Dat is niet de ARP-tabel want dat is een mapping IP->MAC. Die werkt op L3. Bovendien ben je te laat

[Osiris]

RayNbow schreef op maandag 29 augustus 2011 @ 18:32:
[...]

Hoe moet een client achterhalen of een geinjecteerd script geinjecteerd is?

CyBeR schreef op maandag 29 augustus 2011 @ 18:37:
[...]


Lees jij voor elke website die je bezoekt de source door? Kun jij vervolgens het verschil zien tussen een echt script en een geinjecteerd script? Bedenk je wel, als je scripts kun injecteren kun je het ook laten lijken alsof je geinjecteerde scripts vanuit de bron die je tracht te bezoeken komen.

Is natuurlijk zo. En wordt ook aangekaart op dat blog idd. Maar als MITM probeer je, lijkt me, 100% stealth te blijven. Elke methode die jouw aanwezigheid ook maar kán aantonen is een methode die je niet wenst te gebruiken. Dus IMO kun je je afvragen of een javascriptinjectie zo reeël is IRL.

Sowieso 1000x beter dan plain-text

[CyBeR]

Osiris schreef op maandag 29 augustus 2011 @ 18:42:
Is natuurlijk zo. En wordt ook aangekaart op dat blog idd. Maar als MITM probeer je, lijkt me, 100% stealth te blijven. Elke methode die jouw aanwezigheid ook maar kán aantonen is een methode die je niet wenst te gebruiken. Dus IMO kun je je afvragen of een javascriptinjectie zo reeël is IRL.

Neuh. Dat is geheel passief en dat is nuttig bij zeer security-concious mensen die inderdaad al dat soort shit na gaan zitten lopen, als je specifiek die persoon target. Maar het geval wil dat het grote publiek veel interessanter is en dat allemaal níet doet (of überhaupt kan). Dus dan maakt 't niet zo uit of je iets detecteerbaars injecteert, zolang je maar niet té obvious bent.

Vergeet niet dat we leven in een wereld waar elke dag duizenden mensen in een 419 trappen, of die hun info invoeren in een scam site die een bank tracht na te doen.

[ Voor 9% gewijzigd door CyBeR op 29-08-2011 18:45 ]

[TrailBlazer]

yep het is idd veel minder moeite om gewoon iemand op te bellen namens $provider en te vragen om diens wachtwoord omdat ze zien dat er fraude gepleegd wordt met hun account. Social hacking is zoveel makkelijker.

[CoolGamer]

Osiris schreef op maandag 29 augustus 2011 @ 18:42:
Is natuurlijk zo. En wordt ook aangekaart op dat blog idd. Maar als MITM probeer je, lijkt me, 100% stealth te blijven. Elke methode die jouw aanwezigheid ook maar kán aantonen is een methode die je niet wenst te gebruiken. Dus IMO kun je je afvragen of een javascriptinjectie zo reeël is IRL.

100% stealth is al niet mogelijk met ARP spoofing, zoals ik eerder zei. Er zijn firewalls die dat kunnen detecteren. 0% detecteerbaarheid is nooit een eis, je bent uiteindelijk altijd te ontdekken. Als de kans pakkans klein is, is dat voldoende. En dat is het geval bij ARP-spoofing, DNS-corruptie of de javascript aanpassen.

Sowieso 1000x beter dan plain-text

Het helpt inderdaad tegen sniffers, dus het is al wat beveiliging. Maar de beveiliging is nog lang niet op het niveau van bijvoorbeeld SSL.

[Kain_niaK]

TheCoolGamer schreef op maandag 29 augustus 2011 @ 18:12:
Alles wat via HTTP loopt i.p.v. HTTPS kan worden onderschept d.m.v. een man-in-the-middle. In de tweet wordt gezegd dat je kan inloggen via SSL, maar dat heb ik niet kunnen vinden. Ook als er gebruik wordt gemaakt encryptie in javascript kan het wachtwoord in theorie worden onderschept (de man-in-the-middle kan de encryptie weghalen). Een man-in-the-middle-aanval opzetten is op sommige netwerken lastiger dan andere. Op een onbeveiligd netwerk is het niet moeilijk, maar op een goed beveiligd bedrijfsnetwerk worden zulk soort dingen automatisch opgemerkt worden. Er zijn ook firewalls die ARP-attacks kunnen detecteren.

Zo'n valse ARP-update wordt continu gestuurd, waarbij een verzoek van de client op een update niet vereist is. Zodra er een update is wordt de cache overschreven.

Ook SSL is niet meer veilig. Met SSLstrip voer je een man in de middle attack uit.
SSLstrip werkt met ARP spoofing en verandert alle https links in http link.
Je slachtoffer communiceert met jou systeem over http en jij communiceert met de site over https en verstuurd alle communicatie door naar je slachtoffer en andersom.
Dus kun je alle communicatie decrypten.

http://www.thoughtcrime.org/software/sslstrip/
http://www.securitytube.net/video/193


Maar zoals al eerder gezegd.
Als je al op een netwerk aan ARP spoofing kunt doen kun je ook DNS request zelf gaan antwoorden met ip adressen van je eigen server erin. En dan maak je gewoon de website waar je inlog gegevens van wilt zo goed als je kunt na. Heb je ook zo alles te pakken.
Na een submit van je slachtoffer stuur je ze meteen door naar het juiste ip.

[ Voor 11% gewijzigd door Kain_niaK op 29-08-2011 19:10 ]

[SinergyX]

Let wel, je wachtwoord, welke je mogelijk op meerdere websites gebruikt, wordt in plaintext in je mailbox geplaatst. Langs hoeveel hop's het mailtje gaat zullen we maar niet gaan tellen, en dat jij je mail direct uitleest via je mail client waarbij wederom talloze hops gepasseert worden slaan we ook even over. Feit blijft dat al deze stations jouw wachtwoord in plaintext voorbij zien komen. En dus makkelijk kunnen sniffen

Ik dacht dat emailclients via https (danwel webmail) toch ook gewoon encrypted blijven? Dat geval vind ik dit beetje erg goedkoop door de bocht.

[TrailBlazer]

https: of imaps: is idd wel geencrypt het gaat erom dat er een plain-text mailtje met daarin je wachtwoord langs verschillende mailservers gaat. Die mail-admin zou dan je e-mail kunnen zien terwijl het in transit is op dat moment. Als het verkeer tussen die mail servers onderling ook niet geencrypt wordt kan iemand dat ook onderscheppen in theorie.
IT is gewoon een industrie die door miljoenen mensen wereldwijd in de lucht gehouden wordt. Die mensen zouden dingen kunnen doen die niet horen idd. Ik denk alleen dat er maar heel weinig mensen zijn die dat doen.

[CoolGamer]

Kain_niaK schreef op maandag 29 augustus 2011 @ 19:06:
Ook SSL is niet meer veilig. Met SSLstrip voer je een man in de middle attack uit.
SSLstrip werkt met ARP spoofing en verandert alle https links in http link.
Je slachtoffer communiceert met jou systeem over http en jij communiceert met de site over https en verstuurd alle communicatie door naar je slachtoffer en andersom.
Dus kun je alle communicatie decrypten.

Als je zelf https voor de url zet ben je niet te pakken voor die aanvallen. "Niet méér veilig" is een beetje misleidend vind ik zelf. Dit was al vanaf begin af aan bekend.

SinergyX schreef op maandag 29 augustus 2011 @ 19:10:
[...]

Ik dacht dat emailclients via https (danwel webmail) toch ook gewoon encrypted blijven? Dat geval vind ik dit beetje erg goedkoop door de bocht.

Https is alleen tussen jou en de mailserver van je provider. De provider kan dan de inhoud van de mail bekijken. De provider stuurt dan het bericht door naar de mailserver van het doel. Tijdens die verbinding wordt het meestal (niet altijd) weer opnieuw encrypt.

[Kain_niaK]

TheCoolGamer schreef op maandag 29 augustus 2011 @ 19:15:
[...]

Als je zelf https voor de url zet ben je niet te pakken voor die aanvallen. "Niet méér veilig" is een beetje misleidend vind ik zelf. Dit was al vanaf begin af aan bekend.
[...]

Ja wel, want dat is juiste de grootte kracht van een man in de middle attack.
Alles loopt via de aanvaller.
Dus als jij https voor die url zet, de man in de middle verandert het in http en stuurt dan pas de aanvraag door naar de betreffende site.

Does an MITM on the HTTP connection
Replaces all the HTTPS links with HTTP ones but remembers the links which were changed
Communicates with the victim client on an HTTP connection for any secure link
Communicates with the legitimate server over HTTPS for the same secure link
Communication is transparently proxied between the victim client and the legitimate server
Images such as the favicon are replaced by images of the familiar "secure lock" icon, to build trust
As the MITM is taking places all passwords, credentials etc are stolen without the Client knowing

Source: http://www.securitytube.net/video/157

[ Voor 37% gewijzigd door Kain_niaK op 29-08-2011 19:43 ]

[blaataaps]

Kain_niaK schreef op maandag 29 augustus 2011 @ 19:42:
[...]


Ja wel, want dat is juiste de grootte kracht van een man in de middle attack.
Alles loopt via de aanvaller.
Dus als jij https voor die url zet, de man in de middle verandert het in http en stuurt dan pas de aanvraag door naar de betreffende site.

Onzin, zijn punt is nou juist dat dat niet kan.

[CoolGamer]

Zo werkt https niet. Https controleert of je echt verbonden bent met juiste server en niet met bijvoorbeeld een man-in-the-middle. Als dat niet klopt geeft de browser gelijk een error (al is die error wel weg te klikken). Omdat de verbinding is gecodeerd kan de man-in-the-middle niks lezen of veranderen. Meer info.

[Osiris]

Kain_niaK schreef op maandag 29 augustus 2011 @ 19:42:
[...]

Ja wel, want dat is juiste de grootte kracht van een man in de middle attack.
Alles loopt via de aanvaller.
Dus als jij https voor die url zet, de man in de middle verandert het in http en stuurt dan pas de aanvraag door naar de betreffende site.

Hoe wilde je dat doen dan?

Als jij als client https in je browser's adresbalk invoert, dan maakt jouw browser daadwerkelijk een TLS/SSL-handshake met die server. Inclusief het ondertekende certificaat. Je kúnt die TLS/SSL-sessie niet 'zomaar' kapen als MITM.

Pas zodra er https-linkjes in een eerder onbeveiligde verbinding voorkomen, dán zou zoiets kunnen ja.

[Kain_niaK]

Wel als je toegang hebt tot het LAN van je slachtoffer.
Met ARP cache poisoning/Spoofing kun je al het externe verkeer (WAN to LAN) dat bedoelt is voor je slachtoffer naar je eigen IP sturen (dus je IP op het LAN netwerk, je moet toegang hebben tot het LAN netwerk)

Kijk die video maar die ik net poste.
http://www.securitytube.net/video/157

Ook https is dan niet meer veilig.

[Osiris]

Kain_niaK schreef op maandag 29 augustus 2011 @ 19:50:
Wel als je toegang hebt tot het LAN van je slachtoffer.
Met ARP cache poisoning/Spoofing kun je al het externe verkeer (WAN to LAN) dat bedoelt is voor je slachtoffer naar je eigen IP sturen (dus je IP op het LAN netwerk, je moet toegang hebben tot het LAN netwerk)

Kijk die video maar die ik net poste.
http://www.securitytube.net/video/157

Ook https is dan niet meer veilig.

Van diezelfde pagina, stap 1: Does an MITM on the HTTP connection

Tadaa.. Dus als je zélf https invult: pech. (Video laadt hier niet.)

---

Snap nu overigens zelf enigszins waarom T.net geen SSL/TLS aanbiedt:

ApacheBench naar m'n lokale server, via HTTP:

Time per request:       2.150 [ms] (mean)

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     1    2  30.6      1    2166
Waiting:        1    2  30.6      1    2166
Total:          1    2  30.6      2    2167

ApacheBench naar m'n lokale server, via HTTPS (4096-bits keys):

Time per request:       266.984 [ms] (mean)


Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      243  264  29.8    252     538
Processing:     2    2   0.5      2       6
Waiting:        2    2   0.4      2       6
Total:        245  266  30.0    254     541

Anders duurt dat eventjes 133x zo lang om een simpele TCP-verbinding op te zetten Ok, toegegeven, mijn server heeft slechts 2533 MHz-jes tot z'n beschikking en ik maak gebruik van een achterlijk 4096-bits certificaat Maar het geeft wel enigszins aan wat voor schalings-problemen je krijgt bij een drukke site.

OK, met 1024-bits keys gaat 't al een stukkie rapper (en is dus je performance-impact minder groot)

Time per request:       43.287 [ms] (mean)


Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       38   40   5.9     39      97
Processing:     2    3   1.9      2      27
Waiting:        2    3   1.9      2      27
Total:         40   43   6.6     41     103

Maar 1024-bits RSA-keys schijn je liever niet te moeten gebruiken. Heb alleen geen 2048-bits certificaat rondhangen om te testen.

[ Voor 60% gewijzigd door Osiris op 29-08-2011 20:03 ]

[RobIII]

FYI: plan: Development-round-up augustus 2011 - iteratie #4

[Kain_niaK]

Wat er nu gebeurd is waarschijnlijk dat je browser een waarschuwing geeft in verband met een niet te vertrouwen certificaat. Tot er natuurlijk hackers zijn die echte certificaten in handen krijgen of kopen.
Of ik moet hier iets niet begrijpen maar volgens mij kan dit echt.

[TrailBlazer]

Je hoeft ook niet voor elke sessie SSL te gebruiken enkel die sessie waarin je beveiligde data verstuurt. Dat een plaatje clear text over de lijn gaat maakt niks uit natuurlijk.

[CoolGamer]

Kain_niaK schreef op maandag 29 augustus 2011 @ 20:10:
[afbeelding]

Wat er nu gebeurd is waarschijnlijk dat je browser een waarschuwing geeft in verband met een niet te vertrouwen certificaat. Tot er natuurlijk hackers zijn die echte certificaten in handen krijgen of kopen.
Of ik moet hier iets niet begrijpen maar volgens mij kan dit echt.

Je browser geeft dan inderdaad een waarschuwing. Voorbeeld van zo'n error. Maar het is voorgekomen dat certificaten onterecht zijn verstrekt.

[Kain_niaK]

Dan kan het toch ook werken als jij zelf https in typt ?
Of zie ik iets over mijn hoofd ?

[CoolGamer]

Ja, maar het is wel erg opvallend dat ermee is gerommeld. Bij gewone http kan je het haast volledig ongezien doen.

[Verwijderd]

Kain_niaK schreef op maandag 29 augustus 2011 @ 20:10:
[afbeelding]

Wat er nu gebeurd is waarschijnlijk dat je browser een waarschuwing geeft in verband met een niet te vertrouwen certificaat. Tot er natuurlijk hackers zijn die echte certificaten in handen krijgen of kopen.
Of ik moet hier iets niet begrijpen maar volgens mij kan dit echt.

Doe dit nu eens met een EV certificaat? En ja, over een tijdje krijg je niks anders meer, want non-EV certificaten zijn niets meer waard.

[CyBeR]

Verwijderd schreef op maandag 29 augustus 2011 @ 20:29:
[...]

Doe dit nu eens met een EV certificaat? En ja, over een tijdje krijg je niks anders meer, want non-EV certificaten zijn niets meer waard.

EV-certs zijn gewoon certs met een extra vlaggetje. Denk je werkelijk dat een haxx0rer dat vlaggetje niet ook kan aanzetten?

[Kain_niaK]

Voor een site zoals gmail, paypal, of ander belangrijke sites zal ik een waarschuwing van firefox dat een certificate invalid is zeker te harte nemen.

Maar ik heb het al zo vaak gehad dat ik een site wil bezoeken en dat het niet lukt met firefox omdat ik zo'n melding krijg.

Meestal doe ik dan een eenmalige uitzondering. Omdat het vaak voorkomt dat er geen hackers bezig zijn maar dat de site een foutje heeft gemaakt.

[CoolGamer]

EV is kwa beveiliging tussen server-client net zo goed als de standaard https-verbinding. Er is alleen wat meer controle voordat het certificaat wordt uitgegeven.

[TrailBlazer]

een certificaat zegt enkel wat over de authenticiteit van de site en niks over de security tussen jou en die site.

[Osiris]

TrailBlazer schreef op maandag 29 augustus 2011 @ 20:33:
een certificaat zegt enkel wat over de authenticiteit van de site en niks over de security tussen jou en die site.

Ehm, in principe dus wel m.b.t. de security in zoverre dat je weet dat je inderdaad met de juiste partij aan het communiceren bent. Authenticiteit lijkt me toch echt een MAJOR onderdeel van de security in z'n totaliteit. Wat voor symmetrisch encryptie-protocol er vervolgens gebabbeld wordt, tja, minder boeiend (Zolang 't maar veilig is )

[PolarBear]

Maar oud nieuws, zie mijn draadje uit 2003: Secure login

[crisp]

ValHallASW schreef op maandag 29 augustus 2011 @ 17:19:
[...]

Elementary, my dear Watson! ;-)

1. md5(a) => b, vanuit b kan je a niet gemakkelijk bepalen
2. het inloggen gebeurt mbv md5(md5(pwd) + uid + sid).
3. sid is een waarde die iedere keer anders is ('nonce')

hieruit volgt dat de server niet md5(md5(pwd) + uid + sid) opgeslagen kan hebben. De server moet derhalve toegang hebben tot de losse onderdelen daarvan:

md5(pwd), uid, sid

Dat de server toegang heeft tot uid en sid is niet gek, maar de server moet dus óók toegang hebben tot md5(pwd), en zoals wij allen weten zijn er genoeg md5-rainbowtables in omloop om daar ongelukkig van te worden.

(ik hoop dat mijn uitleg een beetje duidelijk is; zo niet, roep vooral, dan zal ik proberen het te verduidelijken)

Dit was waar tot vandaag, zie ook plan: Development-round-up augustus 2011 - iteratie #4 - kortom: we waren ons al langer bewust van de zwakheid van onze wachtwoord-opslag, en dankzij een recente security-audit konden we dit eens een keer prioriteit geven. Scenario's zoals MiM-attacks of keyloggers zijn daarbij (nog) niet in overweging genomen. Wat belangrijker is is dat de audit geen attack-scenario's heeft opgeleverd waarbij password-hashes van gebruikers verkregen konden worden, en dat dat laatste nu dus ook ueberhaupt geen issue meer is omdat alle wachtwoorden nu ook salted zijn.

[Verwijderd]

Wel mooi dat ook uitgerekend vandaag een vals google.com certificaat wordt uitgegeven.
Even voor de duidelijkheid, via zo'n certificaat kan je dus zelfs HTTPS 'sniffen'
Uiteraard ook even over geblogt!

[ Voor 9% gewijzigd door Verwijderd op 30-08-2011 00:39 ]

[Kain_niaK]

Hier is de link.
nieuws: 'Iran gebruikt Nederlands certificaat om Gmail te onderscheppen'


en de link naar Arthy zijn blog http://rickey-g.blogspot....rtificaat-uitgegeven.html

[ Voor 22% gewijzigd door Kain_niaK op 30-08-2011 10:56 ]

[Verwijderd]

Overigens vind ik het wat kort door de bocht hoe personen hier reageren over het vertrouwen op internet. Internet wordt beheert door van alles en iedereen, en die van alles en iedereen kan invloed hebben op het verkeer.
Je moet niet vergeten dat een ip-tap door politie het zelfde zal gaan worden als een telefoon tapje.
Daarbij als je op dit moment TOR gebruikt is de kans vrij groot dat jouw login gegevens van tweakers bij een exit node al reeds zijn gesniffed. Zeker mocht je zonder hashing inloggen of je wachtwoord hebben aangepast.
Kan je dus keurig je ip verstopt hebben via TOR, je username ligt open en bloot op tafel...

[leuk_he]

t.net is geen site waar bankzaken besproken worden. Zoveel waarde moet je niet hechten aan een t.net identitiet. Een vastberaden hacker kan wellicht jouw identiteit overnemen. Maar wat is er dan gewonnen? Wordt dan heel je karma store leeggeroofd? Gaat die persoon spammen met jouw account?

Karma is maar een nummer.
Spammen kan veel simpler dan eerst een identiteit roven.
Je kunt simpel via email je account terugnemen.

Het is niet voor niks dat cookies (die je kun je denk ik overigens ook onderscheppen op een open wifi) tot een jaar geldig zijn. Je t.net identiteit is iets simpels.

het argument dat je je wachtwoord ook op andere sites gebruikt is niet erg sterk. Je kunt namelijk geen enkele site vertrouwen dat er niet een evil admin achter zit die je wachtwoorden probeert op andere sites. De enige oplossing daarvoor is unieke wachtwoorden op elke site, en om dat beheersbaar te houden gebruik je daarvoor een lokale wachtwoorden store die je wel goed beveiligd.

Verwijderd schreef op dinsdag 30 augustus 2011 @ 11:53:
Kan je dus keurig je ip verstopt hebben via TOR, je username ligt open en bloot op tafel...

Mee eens. Je moet goed snappen dat tor enkel je ip verstopt, niet de inhoud van je data.

[ Voor 13% gewijzigd door leuk_he op 30-08-2011 12:08 ]

[Femme]

Wat betreft het plaintext versturen van een zelf opgegeven wachtwoord na registratie (opmerking in Rickey Gevers' blog): dat is een probleem waar we recentelijk ook zelf achter waren gekomen bij het testen van de nieuwe wachtwoordopslag. Wij registeren niet zo vaak op onze eigen website, vandaar dat het niet is opgevallen. Het probleem zal zsm gefixed worden.

[CyBeR]

Femme schreef op dinsdag 30 augustus 2011 @ 23:23:
Wat betreft het plaintext versturen van een zelf opgegeven wachtwoord na registratie (opmerking in Rickey Gevers' blog): dat is een probleem waar we recentelijk ook zelf achter waren gekomen bij het testen van de nieuwe wachtwoordopslag. Wij registeren niet zo vaak op onze eigen website, vandaar dat het niet is opgevallen. Het probleem zal zsm gefixed worden.

Toevallig is 't iets wat wij ook doen en waar ik ook laatst perongeluk achter gekomen ben.. Wordt er bij ons ook uitgesloopt voor die situaties waar je niet een nieuw gegenereerd wachtwoord toegestuurd krijgt.

[Gomez12]

Femme schreef op dinsdag 30 augustus 2011 @ 23:23:
Wat betreft het plaintext versturen van een zelf opgegeven wachtwoord na registratie (opmerking in Rickey Gevers' blog): dat is een probleem waar we recentelijk ook zelf achter waren gekomen bij het testen van de nieuwe wachtwoordopslag. Wij registeren niet zo vaak op onze eigen website, vandaar dat het niet is opgevallen. Het probleem zal zsm gefixed worden.

Tja, simpelweg niets versturen is ook weer niet iets wat je wilt vanuit user-perspectief (gebeurt vaak genoeg dat ik registratie mails erbij pak om het ww te achterhalen)

Dus je zal weer een redelijk gebruikersvriendelijk iets op moeten zetten als vervanging daarvoor. Veilige vragen ed vind ik nooit een alternatief (voor sites waar ik eenmalig geregistreerd heb en 3 maanden later nog eens langskom in ieder geval), ik wens jullie hiermee dus veel geluk

Het zijn imho voornamelijk security vs gebruikersvriendelijkheid issues (enkel https login zou iets zijn).

Maarja, sowieso vind ik die wachtwoord vergeten functies een compromis van veiligheid vs gebruikersvriendelijkheid. Mail is plaintext, dus wat je dan ook via mail verstuurt heeft hetzelfde probleem als het wachtwoord zelf versturen...

[Verwijderd]

Er zijn wel constructies te bedenken om dat veiliger te maken, maar ik denk niet dat er mensen zijn die zich zorgen maken om de veiligheid van een recover password optie... Dat wachtwoord verander je toch meteen.

En bovendien, het is veiligheid of gebruiksvriendelijkheid. Tenzij iemand een constructie kan bedenken die net zo gebruiksvriendelijk is als het huidige password-mail form.

[ACM]

Verwijderd schreef op dinsdag 30 augustus 2011 @ 23:57:
Tenzij iemand een constructie kan bedenken die net zo gebruiksvriendelijk is als het huidige password-mail form.

't Gaat om de mail die je na registratie krijgt, waar ook je (zelf gekozen) wachtwoord in staat.

[Keiichi]

Heel dat artikel gaat alleen maar om het feit van het wachtwoord en plaintext.

Kun je dan niet gewoon stellen dat elke willekeurige site die met wachtwoorden werkt per definitie over SSL moet werken?

En verder gaat het dan over de veiligheid per gebruiker apart. Als iemand m'n t.net naam kaapt, dan blijven alle andere ongemoeid volgens mij, dus is er met de site an sich niets mis.

[Osiris]

Keiichi schreef op woensdag 31 augustus 2011 @ 09:11:
Kun je dan niet gewoon stellen dat elke willekeurige site die met wachtwoorden werkt per definitie over SSL moet werken?

Ik denk dat je die stelling uit kunt breiden met 'sessies' (via cookies), aangezien dat ook een security-risk oplevert in principe.

Helaas kan ik me voorstellen dat TLS/SSL nogal wat impact heeft op je server(-park).

[ Voor 4% gewijzigd door Osiris op 31-08-2011 15:34 ]

[ACM]

Osiris schreef op woensdag 31 augustus 2011 @ 15:33:
Helaas kan ik me voorstellen dat TLS/SSL nogal wat impact heeft op je server(-park).

En om het goed werkend te maken in IE7 en IE8 moet je dan ook al je afbeeldingen, etc via SSL doen. Dus dat maakt het in ons geval nog wat lastiger omdat we die juist expres via varnish laten lopen (die geen ssl spreekt).

We zijn wel bezig met HTTPS, maar echt triviaal is de uitrol ervan niet.

[CyBeR]

ACM schreef op woensdag 31 augustus 2011 @ 17:41:
[...]

En om het goed werkend te maken in IE7 en IE8 moet je dan ook al je afbeeldingen, etc via SSL doen. Dus dat maakt het in ons geval nog wat lastiger omdat we die juist expres via varnish laten lopen (die geen ssl spreekt).

Daar zou je dan inderdaad nog een laagje voor moeten doen.

Ik weet niet meer wat voor load balancing jullie tegenwoordig gebruiken maar sommige load balancers ondersteunen ook SSL termination. Mischien iets om naar te kijken.

We zijn wel bezig met HTTPS, maar echt triviaal is de uitrol ervan niet.

En dan hebben jullie nog maar een site (of iig, alles is te doen met *.tweakers.net.) Waar ik werk hebben een beetje hetzelfde punt maar dan met 60 sites ofzo

[alt-92]

Kain_niaK schreef op maandag 29 augustus 2011 @ 19:50:
Wel als je toegang hebt tot het LAN van je slachtoffer.

offtopic:
...and we're already on the other side of the airlock.

[Kain_niaK]

Ja, maar hoe doe je een MITM attack als je niet op hetzelfde subnet zit als je slachtoffer ?

[CyBeR]

Iraanse overheid wel's van gehoord?

[Keiichi]

Osiris schreef op woensdag 31 augustus 2011 @ 15:33:
[...]
Helaas kan ik me voorstellen dat TLS/SSL nogal wat impact heeft op je server(-park).

Of je CA word opeens geblocked door alle browsers omdat ze certificaten ondertekend hebben die ze niet mochten ondertekenen

[LuckY]

Kleine extra tip:
Graag de mogelijkheid om bij artikelen in te loggen securen.
Dit gaat niet over SSL maar wat erger is, hier wordt ook niet de JS "crypt" gebruikt aka plaintext over de lijn

Dit lijkt me niet ideaal

[ACM]

Helaas, door browser-beperkingen kan dat niet. Dat hadden we namelijk eerst in onze testomgeving, maar het blijkt dat je geen ajax-request mag doen naar de https-server van hetzelfde domein (want dat is blijkbaar ook cross-domain)...

Dus we breiden binnenkort dat formuliertje uit met de melding dat als je via SSL wilt inloggen, dat je dan even een omweg moet nemen.

[crisp]

De JS-encryptie kan daar natuurlijk wel gebruikt worden, maar uiteraard is dat ook slechts een 'lapmiddel' (en is het volledig afhankelijk van javascript)

[LuckY]

@ACM mooi dan weten mensen het in iedergeval wel

@crisp, het is jaren voldoende geweest bij t.net voor zover ik weet dus ook al is het een lapmiddel het beschermd "een beetje" en dat beetje kan best fijn zijn als je het niet weet

[vliegjong]

de vraag die ik mezelf altijd stel, hoe boeiend is het als iemand mijn pass weet? Je dient verschillend PWD's te gebruiken en freedom of the Internet is al lang achterhaald door partijen als Google, Microsoft etc.

Security zwakheden zitten vaak bij de mensen zelf, niet anders dan dat