Userbase

Hey,

ik had reeds Internet Favorite van Belgacom, vorige week geupgrade naar een Pack met TV.
FON had ik reeds geactiveerd en mijn paswoord ingevoerd.
Nu krijg ik een brief aan met de belangrijke informatie om in te kunnen loggen.
Voor de internetverbinding en mailbox lijkt het paswoord gegenereerd te zijn. (heb ik ook nooit aangepast)
Voor FON staat er echter mijn paswoord in.
Dit heb ikzelf ingevoerd, dus Belgacom bewaart dit duidelijk in plain text.
Dit lijkt me niet zo veilig...

Mja, ergens zal dat inderdaad reversable opgeslagen moeten worden, aangezien de FON-dienst an sich niet door Belgacom wordt geëxploiteerd, maar door FON. Ergens zullen er dus synchonisatie-slagen lopen tussen verschillende databases waarbij wachtwoorden "machineleesbaar" zijn. Vermoedelijk zal FON niet kunnen werken met federated accounts.

Euhm, ik snap niets van wat je bedoelt, maar 'machine leesbaar' is echt niet hetzelfde als mens leesbaar.
Een machine kan perfect een salted hash van een paswoord vergelijken, een persoon (lees hacker) kan hier niets mee.
Het hele concept van een hash is dat die gemakkelijk in 1 richting gaat, maar bijna onmogelijk is om in de andere richting te werken.
BGC kan perfect de hash doorsturen naar FON zodat ik me zo kan authenticeren.

... maar wat als de salt verschilt tussen de systemen? Of het hashingmechanisme?
En zoals je zegt: hashes werken maar in 1 richting, dus als je je wachtwoord naar een ander systeem wilt kunnen overbrengen zal het op een bepaald moment 'machine-leesbaar moeten zijn' (lees: via reversible encryption of zo).

Simpel : als je paswoorden wilt kopiëren van 1 systeem naar een ander MOET je paswoord leesbaar zijn voor de server. Dat wil zeggen, ofwel in plaintext opslagen, ofwel decrypteren on the fly. Hashes werken niet.

In dit geval moet op een bepaald moment de transfer gebeuren van een Belgacom server naar een Fon server (of eventueel omgekeerd). Tenzij ze hun servers integreren (als Fon bv altijd het paswoord checked bij Belgacom of omgekeerd), maar aangezien het om 2 verschillende firma's gaat zal dat wel niet zo werken.

Waarom werken hashes niet?
Je kan toch een hash maken op server 1 (BGC) met SHA 512 als methode bijvoorbeeld.
Deze hash kan je doorsturen naar server 2 (FON).
Als ik dan op server 2 wil aanloggen, typ ik mijn paswoord in, dit wordt volgens dezelfde methode (SHA512) gehasht en die hash kan toch vergeleken worden met de hash.
Ik kan op alle systemen inloggen en geen enkele persoon bij BGC of FON kan mijn paswoord lezen.
Wat mis ik volgens jullie?

EDIT: misschien deze link eens lezen? Ik heb het gevoel dat ofwel jullie iets missen, ofwel ik.

FON zal zijn wachtwoorden met md5 hashen zeker. En wachtwoorden verschillend hashen voor verschillende klanten zullen ze niet willen doen. Of zowel bgc als fon salten hun wachtwoorden, en geen enkele van de twee wil hun salt delen met de andere, wat ook te verstaan is. Dan moeten de wachtwoorden wel in plain text doorgestuurd worden. Niet dat ik het eens ben met hun ontwerpkeuzes, maar het zijn mogelijke redenen/excuses.

Of stel dat de salt gebaseerd is op iedere user zijn klantnummer bij BGC (ik zeg maar iets), dan zou FON ook de klantnummers van Belgacom moeten gaan bijhouden.
Of misschien wordt er ergens helemaal geen hash gebruikt en is het wachtwoord (geen hash) nodig om een private keyfile te kunnen unlocken?

Hallo?
Hash is 1 richting! Zelfs al ken je de methode en de salt, dan kan je nog niet vanuit een hash het paswoord te weten komen.

Jullie zeggen:

meon schreef:Of stel dat de salt gebaseerd is op iedere user zijn klantnummer bij BGC (ik zeg maar iets), dan zou FON ook de klantnummers van Belgacom moeten gaan bijhouden.

depeje schreef:FON zal zijn wachtwoorden met md5 hashen zeker. En wachtwoorden verschillend hashen voor verschillende klanten zullen ze niet willen doen. Of zowel bgc als fon salten hun wachtwoorden, en geen enkele van de twee wil hun salt delen met de andere, wat ook te verstaan is.

Kan dus niet, BGC heeft mij mijn paswoord toegestuurd. Ze doen dus per definitie geen hash (met of zonder salt)

depeje schreef:Dan moeten de wachtwoorden wel in plain text doorgestuurd worden. Niet dat ik het eens ben met hun ontwerpkeuzes, maar het zijn mogelijke redenen/excuses.

Wel, daarin verschil ik volledig in mening met je.
Er zijn geen excuses om een paswoord in plain text te bewaren of door te sturen!

Ondertussen deze blogpost van FON gevonden.

Firstly, Fon does not hold the password of all of the users in the database. In fact, many of our users who are part of the Fon community through one of our telco partners, have their passwords stored by our partners (their ISP or mobile operator). When this is the case, Fon has no access to the passwords at all, as they are not stored in Fon’s database.

Dus het paswoord wordt totaal niet tussen BGC en FON uitgewisseld!
De fout ligt dus volledig bij BGC.

De rest van de blog post maakt eigenlijk de situatie alleen maar meer onduidelijk hoe het er bij FON aan toe gaat.
Het geeft me in ieder geval weinig vertrouwen.

Ok, blijkbaar heeft FON niet het echte paswoord nodig. Goed.

Ik zou het niet echt een fout van BGC noemen. Er zijn veel systemen waar paswoorden op deze manier worden opgeslagen. Niet veilig indien men op de harde schijf geraakt waar ze op staan (maar dan heb je nog meer problemen dan dat), maar normaal in vele systemen, vooral waar erg grote aantallen users en vele verschillende soorten servers door elkaar staan. Federated systems zijn beter, maar ja ... in de praktijk is het dikwijls anders. Overigens worden users soms erg kwaad als je ze aan de hel(l)pdesk moet vertellen dat je ze hun oude paswoord niet kan vertellen, maar dat ze altijd hun paswoord moeten resetten (hehe). Alles heeft voor en nadelen.

Chris_147 schreef:Hallo?
Hash is 1 richting! Zelfs al ken je de methode en de salt, dan kan je nog niet vanuit een hash het paswoord te weten komen.

Dat is ook niet nodig. Ze zouden gewoon de hashes aan elkaar door kunnen geven. Maar daar zijn ze enkel iets mee als ze ook hun salt doorgeven. Als ze dat niet willen...

Chris_147 schreef: Kan dus niet, BGC heeft mij mijn paswoord toegestuurd. Ze doen dus per definitie geen hash (met of zonder salt)

Dat is dus een bewijs dat ze het niet gehashed opslaan, maar zegt nog niet veel over de reden waarom...

Chris_147 schreef:

depeje schreef:Dan moeten de wachtwoorden wel in plain text doorgestuurd worden. Niet dat ik het eens ben met hun ontwerpkeuzes, maar het zijn mogelijke redenen/excuses.

Wel, daarin verschil ik volledig in mening met je.
Er zijn geen excuses om een paswoord in plain text te bewaren of door te sturen!

Je quote zelfs de zin waarin ik laat blijken dat ik het er ook niet mee eens ben .

Voor dit soort zaken zijn veel betere oplossingen: shibboleth.

Als je overal verschillende wachtwoorden gebruikt heb je geen reden om je druk te maken imho Je kan je beter bewust zijn van het feit dat niet alle service providers de wachtwoorden beveiligd opslaan en zelfs als dat wel zo is dat het mogelijk is dat in een man-in-the-middle attack je wachtwoord onderschept wordt. Verschillende wachtwoorden gebruiken voor verschillende toepassingen is dus de boodschap! Zo doe ik het althans Afhankelijk van hoe kritiek de toepassing is kan je je dan nog meer of minder druk maken als je zoiets ontdekt. Maar eerlijk gezegd zijn de enige zaken waar ik mij druk in kan maken gerelateerd aan banken / visa en daar probeer ik altijd te zorgen dat ik met een authenticator kan werken.

Verschillende paswoorden gebruik ik ook.
Maar stel je het volgende voor:
- Belgacom wordt gehackt (niet zo onrealistisch)
(en als ze paswoord in plain text bewaren, geeft me dat ook de indruk dat security niet hoog op hun lijstje staat)
- Hacker verkoopt deze gegevens op het internet
- Pedofiel komt dit tegen en denkt, hey, hiermee kan ik anoniem op het internet (ook niet zo onrealistisch)
- Politie valt bij jou binnen, vind natuurlijk niets, maar ja, bewijzen hebben ze toch al: want dit is jouw geheime paswoord, niet?

@ depeje: lees mijn zin ook nog eens voor je je kop tegen de muur bonkt.
Jij zegt: "...maar het zijn mogelijke redenen/excuses"
ik zeg: "Er zijn geen excuses..."

de "hotspot" software in gebruik (coovachilli) gebruikt een "radius" server...
op een "belgacom" spot zal deze eerst de radius server van Belgacom vragen of het de login gegevens kent, vervolgens bij negatief advies die van FON...
spijtig genoeg bij timeout (vpn pijp tussen Belgacom en Fon overbelast? Heeft de Belgacom radius server te lang op zich laten wachten?)

Het is vrij eenvoudig om te testen of een bedrijf jouw paswoord (salted/hashed) bijhoudt... je voert gewoon de "ik ben mijn paswoord vergeten" methode uit... als hij dan jouw paswoord clear text unencrypted over pop3(email) stuurt... dan is het niet secure opgeslagen...
de enige propere methode is de reset password methode waarbij je een domme secret question moet beantwoorden zeker... (want je oude paswoord ken je niet

Gebeurt niet enkel bij Belgacom. Bij Scarlet slaan ze in plain text mijn zelfgekozen wachtwoord van mijn verbinding op, daar kon ik ook niet met lachen toen ik daar achter kwam... Met wachtwoorden moet voorzichtig omgesprongen worden.

Hetzelfde gemerkt als de technieker kwam.
Ik keur dit ook niet goed, maar op de moment van installatie werkte ZTC niet, nu ja ik weet het wachtwoord, maar hoe zit dat met de niet-techneuten?

Chris_147 schreef:Maar stel je het volgende voor:
- Belgacom wordt gehackt (niet zo onrealistisch)
(en als ze paswoord in plain text bewaren, geeft me dat ook de indruk dat security niet hoog op hun lijstje staat)

Het incident waarnaar je refereert, van de hacker die login paswoorden uit de modem haalde, was geen Belgacom hack. Achteraf bleek dat de ontvreemde paswoorden niet kwamen van gehackte BBoxen, maar van klanten die een eigen (niet goed beveiligde) modem gebruikten, waarop de hacker remote kon inloggen.

MClaeys schreef:Gebeurt niet enkel bij Belgacom. Bij Scarlet slaan ze in plain text mijn zelfgekozen wachtwoord van mijn verbinding op, daar kon ik ook niet met lachen toen ik daar achter kwam... Met wachtwoorden moet voorzichtig omgesprongen worden.

Ik vind het ook irritant dat je het paswoord van de telefoonverbinding niet kan veranderen bij Scarlet.