Vodafone versleutelt wachtwoorden van klanten niet
Wachtwoorden van Vodafones klantendienst MyVodafone staan onversleuteld opgeslagen in een database. Dat zegt de provider in antwoord op vragen van Tweakers.net. Een tweaker kwam de gebrekkige beveiliging op het spoor.
Vodafone zegt in een statement tegen Tweakers.net dat er wel beveiliging aanwezig is. "De wachtwoorden worden opgeslagen in een database die via verschillende netwerklagen en firewalls is afgeschermd", aldus woordvoerder Jasper Koek. Er is voor zover nu bekend dan ook geen sprake van dat de beveiliging is gekraakt; gegevens van klanten liggen niet op straat.
Tweaker DennusB kwam de gebrekkige beveiliging vorige week op het spoor, toen hij zijn wachtwoord wilde resetten. Tot zijn verbazing kreeg hij zijn wachtwoord in plain text toegestuurd per sms. Vodafone bezweert dat niemand behalve de klant het wachtwoord kan zien.
De provider gaat aan de slag om de wachtwoorden te versleutelen, zegt Koek. "Het is een prioriteit voor ons. We weten niet wanneer de versleuteling toegepast zal zijn." De versleuteling van de wachtwoorden in de database stond al op het programma voordat de meldingen van DennusB en Tweakers.net binnenkwamen. "Het is een extra bevestiging voor ons dat dit belangrijk is."
MyVodafone is de klantendienst van Vodafone, waarin klanten hun abonnementen kunnen beheren en hun verbruik kunnen bijhouden. Een aanzienlijk deel van de klanten gebruikt de dienst, waardoor het al snel om honderdduizenden tot enkele miljoenen wachtwoorden gaat.
Het is niet de eerste keer dat MyVodafone in opspraak komt wegens een gebrek aan beveiliging. De iOS-app bleek inloggegevens onversleuteld te versturen.
Reacties (189)
Datzelfde geldt voor de database van oa KPN Glasvezel. Belde pas met ze, in het gesprek werd mij gevraagd "Begint uw wachtwoord met 123, daarna een letter, een cijfer en weer twee cijfers?"
Alle wachtwoorden bij Telfort staan ook onversleuteld in de database...
Klopt, telfort helpdesk medewerkers kunnen je wachtwoord gewoon zien
Bij XMS ook. Ze mochten het wachtwoord niet afgeven maar konden het wel inzien.
Bij UPC alleen het wachtwoord voor de e-mail mits de klant deze niet verandert. Als deze veranderd is kan UPC geen wachtwoorden inzien 
T-mobile kan ook aan het lijstje worden toegevoegd. Die sturen het per SMS onversleuteld.
Als we dan toch bezig zijn: Ben.nl stuurt je wachtwoord per email in "plain text" op als je deze bent vergeten.
Met een dergelijke policy vrees ik het ergste mbt de manier waarop het is opgeslagen.
Met een dergelijke policy vrees ik het ergste mbt de manier waarop het is opgeslagen.
Toen ik op de helpdesk werkte van Planet/HetNet konden we wachtwoorden achterhalen van klanten. Nieuwe wachtwoorden werden per post verzonden en alle poststukken waren op te vragen als PDF. Later bij Orange/Online gewerkt, daar stonden wachtwoorden gewoon plaintext in de database.
Dit was jaren geleden, mag hopen dat ze de boel beter beveiligd hebben nu.
Dit was jaren geleden, mag hopen dat ze de boel beter beveiligd hebben nu.
Bij (tegenwoordig T-Mobile) Online is dat nog steeds zo. Het staat er wel encrypted in, en alle systemen waar de klant mee te maken krijgen lezen die ook uit, alleen als het wachtwoord verandert schrijft het systeem hem in een apart veld ook nog even in plain text weg.
[Reactie gewijzigd door WebHawk op vrijdag 29 juni 2012 19:06]
Mijn God, hebben ze dan niks geleerd de afgelopen tijd.
@ Jism
T-mobile medewerkers kunnen het wachtwoord niet inzien, op het moment dat je het wachtwoord kwijt bent moet deze gereset worden. Dit gebeurt zowel bij het aanvragen van een nieuw wachtwoord per sms of als een t-mobile medewerker het wachtwoord moet aanpassen.
edit:
Het klopt inderdaad het dat het tijdelijke wachtwoord (wat dus direct na inloggen aangepast moet worden) in plain text word opgestuurd, maargoed ik zie niet in hoe dit anders zou moeten en hoe dit verschilt met alle duizenden websites (inclusief t.net ) het doen met het resetten van het wachtwoord en het opsturen van een tijdelijk wachtwoord.
T-mobile medewerkers kunnen het wachtwoord niet inzien, op het moment dat je het wachtwoord kwijt bent moet deze gereset worden. Dit gebeurt zowel bij het aanvragen van een nieuw wachtwoord per sms of als een t-mobile medewerker het wachtwoord moet aanpassen.
edit:
Het klopt inderdaad het dat het tijdelijke wachtwoord (wat dus direct na inloggen aangepast moet worden) in plain text word opgestuurd, maargoed ik zie niet in hoe dit anders zou moeten en hoe dit verschilt met alle duizenden websites (inclusief t.net ) het doen met het resetten van het wachtwoord en het opsturen van een tijdelijk wachtwoord.
[Reactie gewijzigd door Creesch op vrijdag 29 juni 2012 17:35]
Ipv een tijdelijk wachtwoord opsturen, is het veel beter om een sleutel op te sturen die bijvoorbeeld een dag geldig is. Deze sleutel kan de gebruiker gebruiken om zijn wachtwoord te resetten. Dit kan bijvoorbeeld via een link werken, of een invulformulier. Hierbij vraag het systeem dan om een nieuw wachtwoord, waarbij er nooit een (tijdelijk) wachtwoord in je e-mail belandt. Dat is voor zover ik weet de beste manier om een wachtwoord te resetten van een gebruiker.
@Loekie: Je kan het originele wachtwoord in je database laten staan, met daarnaast de tijdelijke sleutel. Zo kan dus iemand anders nooit een reset aanvragen voor jouw e-mailadres/gebruiker en jou op één of andere manier dwars zitten. Iemand zou theoretisch kunnen zorgen dat je nooit meer in je account komt als hij/zij constant een reset aanvraagt.
Qua autorisatie is het opsturen van een tijdelijk wachtwoord of een sleutel inderdaad niet anders. Echter is het wel soms zo dat mensen een tijdelijk wachtwoord als permanent wachtwoord gebruiken. Iets dat je ook niet wil hebben. Dit is ook iets dat de tijdelijke sleutel oplost.
@Loekie: Je kan het originele wachtwoord in je database laten staan, met daarnaast de tijdelijke sleutel. Zo kan dus iemand anders nooit een reset aanvragen voor jouw e-mailadres/gebruiker en jou op één of andere manier dwars zitten. Iemand zou theoretisch kunnen zorgen dat je nooit meer in je account komt als hij/zij constant een reset aanvraagt.
Qua autorisatie is het opsturen van een tijdelijk wachtwoord of een sleutel inderdaad niet anders. Echter is het wel soms zo dat mensen een tijdelijk wachtwoord als permanent wachtwoord gebruiken. Iets dat je ook niet wil hebben. Dit is ook iets dat de tijdelijke sleutel oplost.
[Reactie gewijzigd door blizzeye op vrijdag 29 juni 2012 19:18]
Op wat voor manier is een tijdelijk wachtwoord opsturen anders dan een 'sleutel'? Het is een beetje kip vs ei, maar toch.
De maximale geldigheid is dan wel weer goed en kan prima geautomatiseerd werken.
Wachtwoorden mogen inzien is evenals email geregeld onder privacy-wetgeving, dit mag niet omdat het nog weleens persoonlijke informatie kan bevatten en terug te leiden is naar een persoon.
De maximale geldigheid is dan wel weer goed en kan prima geautomatiseerd werken.
Wachtwoorden mogen inzien is evenals email geregeld onder privacy-wetgeving, dit mag niet omdat het nog weleens persoonlijke informatie kan bevatten en terug te leiden is naar een persoon.
In praktische zin komt dit toch op exact hetzelfde neer als een tijdelijk wachtwoord dat de eerste keer veranderd moet worden, of ben ik nou gek?
edit:
Wat Loekie ook zegt.
edit:
Wat Loekie ook zegt.
[Reactie gewijzigd door Cocytus op vrijdag 29 juni 2012 19:19]
Dat laatste probleem lossen wij grotendeels op door de gebruikers te dwingen dat tijdelijke wachtwoord te veranderen bij de eerste login. Dus tenzij de gebruikers dat tijdelijke wachtwoord weer invullen, wordt het gewijzigd
Toen ik mijn internetabonnement van Ziggo wilde activeren ging er iets mis waardoor ik de helpdesk moest bellen om de activatie te voltooien. De helpdeskmedewerker stelde toen gelijk een wachtwoord voor me in.
Ik ga er dus vanuit dat ze m'n wachtwoord ook kunnen bekijken.
@ hieronder:
Ze hebben m'n wachtwoord niet gerestet maar een nieuwe ingesteld. De helpdeskmederwerker vroeg wat m'n nieuwe wachtwoord moest worden, ik gaf het wachtwoord en hij voerde het in.
Ik ga er dus vanuit dat ze m'n wachtwoord ook kunnen bekijken.
@ hieronder:
Ze hebben m'n wachtwoord niet gerestet maar een nieuwe ingesteld. De helpdeskmederwerker vroeg wat m'n nieuwe wachtwoord moest worden, ik gaf het wachtwoord en hij voerde het in.
[Reactie gewijzigd door Vihaio op vrijdag 29 juni 2012 19:50]
Elke helpdesk in een bedrijf kan wachtwoorden resetten, betekent niet dat ze die ook kunnen inzien
als men bij de helpdesk je wachtwoord kan lezen, dan zou men die gewoon geven ipv te resetten
tenzij ze niet willen dat je weet dat ze het kunnen inzien (voorkomt discussie)
(voorkomt discussie)Krijg je dan niet meteen te neiging om je password te veranderen in "WelkeIdiootSlaatIn2012WachwoordenNogOnversleuteldOp"...? 
"...MetEenMaximumLengteVan8Karakters"... Password too long.
Het overzetten van grote corporate systemen naar een nieuwe versleuteling is meestal een lang en duur grapje, dat is de reden -- in 2000 was het nog gebruikelijk en dat systeem is niet veranderd sindsdien. Ik ben het met je eens dat het geen *goede* reden is, maar dat is de reden.
Het overzetten van grote corporate systemen naar een nieuwe versleuteling is meestal een lang en duur grapje, dat is de reden -- in 2000 was het nog gebruikelijk en dat systeem is niet veranderd sindsdien. Ik ben het met je eens dat het geen *goede* reden is, maar dat is de reden.
En dan nog gaat het je niet veel helpen, want dan eisen ze weer dat er minstens één cijfer, één hoofdletter en een leesteken in moet zitten."...MetEenMaximumLengteVan8Karakters"... Password too long.
In plaats van "to be or not to be, that's the question" of de bekende "correct horse battery staple" wat veel beter bestand is tegen een brute-force aanval.
Al is "correct horse battery staple" inmiddels vrij bekend - en dus onveilig, maar dat terzijde. Met andere woirden klopt het wel.
Vind ik vreemd want dit soort dingen staan eigenlijk altijd in een database en met een heel simpele tool kun je de plain text wachtwoorden gewoon omzetten naar iedere versleuteling in een nieuwe database regel....daarna doe je een reroute op je website naar een nieuwe inlogpagina die naar je versleutelde wachtwoord verwijst....
hackerdehack kan het in 15min....
het wordt een ander verhaal als je wachtwoorden al versleuteld zijn, dan moet je langzaam over en ga je iedereen met een nieuw wachtwoord versleutelen en zet je een policy dat je binnen 2 maanden je wachtwoorden moet wijzigen....
hackerdehack kan het in 15min....
het wordt een ander verhaal als je wachtwoorden al versleuteld zijn, dan moet je langzaam over en ga je iedereen met een nieuw wachtwoord versleutelen en zet je een policy dat je binnen 2 maanden je wachtwoorden moet wijzigen....
Een ISP kan dat in de praktijk niet maken, zeggen dat al hun klanten hun wachtwoord moeten wijzigen binnen 2 maanden.
Er zijn wel constructies mogelijk hoor -- Versie 1 van het wachtwoord is onversleuteld, versie 2 is hash1, dat kun je zo omzetten met een scriptje, versie 3 is een hash2 van hash1 van het password en versie 4 is een hash2 van het wachtwoord, je gebruikt een scriptje dat versie 2 in 3 omzet en daarna ga je tijdens de login procedure versie 3 in 4 omzetten, etc.etc.
Maar het is fucking complex en het is *niet* iets dat je als ISP kan laten foutgaan. Daar moet heel erg veel op getest worden.
Er zijn wel constructies mogelijk hoor -- Versie 1 van het wachtwoord is onversleuteld, versie 2 is hash1, dat kun je zo omzetten met een scriptje, versie 3 is een hash2 van hash1 van het password en versie 4 is een hash2 van het wachtwoord, je gebruikt een scriptje dat versie 2 in 3 omzet en daarna ga je tijdens de login procedure versie 3 in 4 omzetten, etc.etc.
Maar het is fucking complex en het is *niet* iets dat je als ISP kan laten foutgaan. Daar moet heel erg veel op getest worden.
Zal je misschien niet lukken, password meer dan 16 tekens?
Niet waar, ze konden alleen de wachtwoorden resetten naar een wachtwoord in de brief, inzien was niet mogelijk
Inderdaad. Telfort "flikt" het ook.Klopt, telfort helpdesk medewerkers kunnen je wachtwoord gewoon zien
Er zijn maar heel weinig websites die een onversleuteld wachtwoord gebruiken.
Misschien moeten er eens boetes uitgedeeld worden wegens het "gelegenheid" geven tot het stelen van privegegevens
Goed, dan wordt het tijd om mijn abbo daar maar eens op te gaan zeggen. Het is werkelijk schandalig dat men zo omgaat met wachtwoorden. Is er geen wetgeving mbt het opslaan van wachtwoorden?
Jawel een hele goeie wet met betrekking tot beveiliging van persoonsgegevens, wat mij betreft vallen wachtwoorden daar ook onder.
Gewoon luiigheid, want een database vercijferen en de toegang regelen is echt maar een paar uurtjes werk.
Gewoon luiigheid, want een database vercijferen en de toegang regelen is echt maar een paar uurtjes werk.
Als ik het zo lees hierboven ben ik benieuwd naar welke telecom provider je gaat overstappen. Ze lijken het bijna allemaal niet goed geregeld te hebben.
Dan belde ik wel toevallig voor gelijk m'n abonnement op te zeggen..
Dan kan je je wel afmelden voor internet, tv en alle online diensten .
Mij is het ook opgevallen, dat heeeeel veel databases onversleutelde wachtwoorden gebruiken. Als je 'forgot password' je eigen plaintext password krijgt, mag je even schrikken.
Ik gebruik om die reden firefox zijn password remember functie, met een masterpassword. Vervolgens krijgt elke site, elk forum een random password.
Niet de beste site, http://www.randpass.com/advanced.html maar goede tool
32 chars, alle 4 classes, kom maar op met de passwords
Hier voorkom je tenminste dat iemand wat met je password kan.
Ik gebruik om die reden firefox zijn password remember functie, met een masterpassword. Vervolgens krijgt elke site, elk forum een random password.
Niet de beste site, http://www.randpass.com/advanced.html maar goede tool
32 chars, alle 4 classes, kom maar op met de passwords
Hier voorkom je tenminste dat iemand wat met je password kan.
Dan kunnen ze nog wel versleuteld in de database staan, alleen niet als hash maar als volledige encryptie.
Datzelfde geldt voor de database van Holland Heineken House.
Is op zich ook logisch. Stel een klant is zijn wachtwoord kwijt. Dan kan ie ook niet bij zijn mail. De helpdesk kan op zo'n moment dus ook niet een password-reset email sturen.
Vrijwel alle klanten vinden dergelijke ondersteuning erg prettig.
Je zou natuurlijk ook de helpdesk medewerker een optie kunnen geven om handmatig een wachtwoord in te voeren, maar op dat moment is het wachtwoord ook al niet meer geheim. En als de beveiligings lagen goed zijn geregeld is dat ook geen probleem.
Daarnaast zijn er ook ontzettend veel partijen welke wel het wachtwoord hashen, maar dan weer geen salt gebruiken waardoor middels een rainbow table die wachtwoorden ook eenvoudig zijn te achterhalen.
Daarnaast speelt bij een hoop providers ook nog legacy systemen een grote rol. Vooral de grote providers bieden nog steeds de mogelijkheid om via een modem in te bellen. En veel oudere PPP-applicaties hebben nog geen ondersteuning om wachtwoorden te hashen.
Ook de DSL/Reggefiber PPP uplink vind in vrijwel alle gevallen plaats met een plaintext wachtwoord. Op eeen DSL netwerk heb je een partij welke voor de verbinding zorgt (in de meeste gevallen KPN of BBned) en een partij welke voor internet toegang zorgt over dat netwerk.
De 'virtuele' provider geeft de logingegevens door aan de partij welke de lijn verzorgt. De VCI/VPI parameters geven aan bij welke provider de klant hoort. De kracht van een salt zou snel komen te vervallen als de providers aan KPN moeten doorgeven wat hun salt is omdat anders KPN niet de hash zou kunnen reproduceren.
Voor netwerk providers is het hashen van wachtwoorden dus helemaal niet zo eenvoudig..
Een betere oplossing zou zijn dat providers voor netwerk toegang een ander wachtwoord zouden hanteren dan voor account instellingen. De eerste kan dan gewoon plaintext blijven voor integratie met andere toegangs systemen, terwijl je mailbox en configuratie panel een ander gehashed wachtwoord hebben.
Maar een dergelijke aanpassing kost een hoop tijd, resources en planning.
Vrijwel alle klanten vinden dergelijke ondersteuning erg prettig.
Je zou natuurlijk ook de helpdesk medewerker een optie kunnen geven om handmatig een wachtwoord in te voeren, maar op dat moment is het wachtwoord ook al niet meer geheim. En als de beveiligings lagen goed zijn geregeld is dat ook geen probleem.
Daarnaast zijn er ook ontzettend veel partijen welke wel het wachtwoord hashen, maar dan weer geen salt gebruiken waardoor middels een rainbow table die wachtwoorden ook eenvoudig zijn te achterhalen.
Daarnaast speelt bij een hoop providers ook nog legacy systemen een grote rol. Vooral de grote providers bieden nog steeds de mogelijkheid om via een modem in te bellen. En veel oudere PPP-applicaties hebben nog geen ondersteuning om wachtwoorden te hashen.
Ook de DSL/Reggefiber PPP uplink vind in vrijwel alle gevallen plaats met een plaintext wachtwoord. Op eeen DSL netwerk heb je een partij welke voor de verbinding zorgt (in de meeste gevallen KPN of BBned) en een partij welke voor internet toegang zorgt over dat netwerk.
De 'virtuele' provider geeft de logingegevens door aan de partij welke de lijn verzorgt. De VCI/VPI parameters geven aan bij welke provider de klant hoort. De kracht van een salt zou snel komen te vervallen als de providers aan KPN moeten doorgeven wat hun salt is omdat anders KPN niet de hash zou kunnen reproduceren.
Voor netwerk providers is het hashen van wachtwoorden dus helemaal niet zo eenvoudig..
Een betere oplossing zou zijn dat providers voor netwerk toegang een ander wachtwoord zouden hanteren dan voor account instellingen. De eerste kan dan gewoon plaintext blijven voor integratie met andere toegangs systemen, terwijl je mailbox en configuratie panel een ander gehashed wachtwoord hebben.
Maar een dergelijke aanpassing kost een hoop tijd, resources en planning.
Dan resetten ze toch naar een wachtwoord dat ze dan telefonisch doorgeven dat je als klant bij 1e inlog moet aanpassen?Is op zich ook logisch. Stel een klant is zijn wachtwoord kwijt. Dan kan ie ook niet bij zijn mail. De helpdesk kan op zo'n moment dus ook niet een password-reset email sturen.
Vrijwel alle klanten vinden dergelijke ondersteuning erg prettig.
Vind het niet acceptabel dat de helpdesk de wachtwoorden kan zien, wie weet welke mensen die wachtwoorden ook voor andere doeleinden gebruiken.. (zullen er veel zijn..)
Of natuurlijk via SMS...
En wat als ik nou met jouw login even een reset aanvraag. Dan kan ik een nieuw wachtwoord op jou account aanmaken.
Bij telenet, hier in belgie. Word een paswoord reset gekoppeld aan je kabelmodem. Deze modem is van telenet zelf en kan niet door de klant aangepast worden. Hierdoor id het een stuk moeilijker om als iemand anders voor te doen.
Bij telenet, hier in belgie. Word een paswoord reset gekoppeld aan je kabelmodem. Deze modem is van telenet zelf en kan niet door de klant aangepast worden. Hierdoor id het een stuk moeilijker om als iemand anders voor te doen.
Jij wilt dat een willekeurige persoon aan de telefoon een nieuw wachtwoord per telefoon doorkrijgt?
Overigens: Mailpasswords moet je onversleuteld opslaan. Pop3 wil je kunnen doen met een plaintext password.
Overigens: Mailpasswords moet je onversleuteld opslaan. Pop3 wil je kunnen doen met een plaintext password.
En waarom wil je ze dan onversleuteld (gehashed) opslaan? Zelfs als het protocol geen versleuteling toestaat (afaik ondersteunt pop3 dat ook overigens) dan nog kun je ze gehashed opslaan. Plain text opslaan is nooit een reden voor.
Zelfs bij POP3 hoeft het achterliggende systeem het plaintext wachtwoord niet op te slaan. Plaintext ww wat binnen komt crypten/hashen/whatever en vergelijken met wat er in de DB staat voor de auth. Mocht de bewuste DB ooit op straat komen is je wachtwoord nog niet meteen bekend (voeg goeie salt toe voor betere resultaten, of niet linkedin)
Alle problemen die je schets zijn eenvoudig op te lossen.
1. Zie CyBerSPiN's comment
2. PPP systemen kunnen misschien niet zelf hashen maar het geeft niet voor ze of de wachtwoorden al gehashed zijn op het moment dat ze binnen komen, zolang ze in het PPP systeem zelf maar consequent zijn, de front/end voor het PPP systeem kan dit doen of je kunt een simpele interface laag tussen PPP en de rest van de systemen zetten.
3. Een salt geheim houden is security through obscurity het idee van een salt is puur al bestaande rainbowtables counteren, daar hoeft de salt niet geheim voor te zijn.
1. Zie CyBerSPiN's comment
2. PPP systemen kunnen misschien niet zelf hashen maar het geeft niet voor ze of de wachtwoorden al gehashed zijn op het moment dat ze binnen komen, zolang ze in het PPP systeem zelf maar consequent zijn, de front/end voor het PPP systeem kan dit doen of je kunt een simpele interface laag tussen PPP en de rest van de systemen zetten.
3. Een salt geheim houden is security through obscurity het idee van een salt is puur al bestaande rainbowtables counteren, daar hoeft de salt niet geheim voor te zijn.
2. het punt is dus met PPP systemen dat die frontend geen hashing aankan. Daar ging het over. Overigens kun je er niet van uit gaan dat een systeem dat is gebouwd op plaintext passwords van 8 karakters zomaar een hash kan doorgeven zonder problemen -- zowel lengte als de karakters erin zijn een probleem.
Je moet ook niet een salt per bedrijf hebben, je moet een salt hebben per user...De kracht van een salt zou snel komen te vervallen als de providers aan KPN moeten doorgeven wat hun salt is omdat anders KPN niet de hash zou kunnen reproduceren.
Je ziet tegenwoordig steeds vaker bij bedrijven dat in het geval van wachtwoord vergeten, deze gereset wordt waarna de werknemer deze na de eerste keer er mee in te loggen verplicht moet wijzigen, dit is uiteindelijk de beste en veiligste oplossing waarmee Helpdesk de klant kan helpen.Je zou natuurlijk ook de helpdesk medewerker een optie kunnen geven om handmatig een wachtwoord in te voeren, maar op dat moment is het wachtwoord ook al niet meer geheim. En als de beveiligings lagen goed zijn geregeld is dat ook geen probleem.
En inderdaad, alle legacy systemen die geen password encryptie ondersteunen, behoren aan een aparte database te hangen, zodat ook deze gevoeligheid dichtgetimmerd is.
Voeg Ben dan ook aan die lijst toe.
Bij wachtwoord vergeten krijg je die ook netjes in plaintext terug
Bij wachtwoord vergeten krijg je die ook netjes in plaintext terug
Bij het Financieel Dagblad werd mij zelfs gevraag is **** uw wachtwoord?
Een grote mobiele payment provider gooit username & password gewoon onversleuteld in de adresbalk als je een factuur probeert te downloaden... ook niet echt handig.. 
Dit ga je niet menen! Ik weet niet tot hoeverre Vodafone gegevens aan jouw account koppelt, maar het lijkt me niet een prettig idee dat hackers kunnen zien met wie je belt! Of zelfs erger, je voicemail kunnen afluisteren / smsjes kunnen lezen.
De vraag is hier om welke wachtwoorden het gaat, en wat je er mee kan doen. Volgens mij gaat het niet om je voicemail wachtwoord.
Laten we de alarmbellen gebruiken voor echt alarm...
Laten we de alarmbellen gebruiken voor echt alarm...
Je wilt niet weten hoe vaak wachtwoorden voor één dienst (MyVodafone) gebruikt worden voor een andere dienst (bijvoorbeeld het bijbehorende email account).
Dus het is zeker wel belangrijk om die shit te salten + hashen
Dus het is zeker wel belangrijk om die shit te salten + hashen
Via My Vodafone kun je gespecificeerde facturen downloaden waarop je inderdaad kunt zien met wie je hebt gebeld en gesms't... Ook kun je bijv. datalimieten uitzetten en diensten (blox e.d.) aan- en uitzetten.
het gaat hier om de MyVodafone omgeving.
En via MyVodafone kun je je gespecificeerde rekening opvragen en dus zien met wie je wanneer hoe lang belde. SMS en voicemail lezen/luisteren is niet mogelijk, maar toch.
Kun je via MyVodafone ook je abonnement aanpassen? Of blox bijkopen of iets dergelijks?
Voor zover ik weet kan je daar je je abbonement verlengen en beheren e.d. Dit houdt dus ook in dat je blox aan en uit kan zetten.Door Arnoud Engelfriet, vrijdag 29 juni 2012 16:18
Kun je via MyVodafone ook je abonnement aanpassen? Of blox bijkopen of iets dergelijks?
Dit is inderdaad mogelijk!Kun je via MyVodafone ook je abonnement aanpassen? Of blox bijkopen of iets dergelijks?
Nou, dat is dus wachten op een hack...
Erg slecht geregeld, aangezien je met een mobiel nummer plus dat wachtwoord alle gegevens van iemand kunt veranderen. (adres, abonnement, verlenging)
Kun je mooi het adres wijzigen, verlengen met een leuk toestel en de eigenaar van het nummer komt er pas achter als hij eigenlijk denkt dat zn abo is afgelopen..
Erg slecht geregeld, aangezien je met een mobiel nummer plus dat wachtwoord alle gegevens van iemand kunt veranderen. (adres, abonnement, verlenging)
Kun je mooi het adres wijzigen, verlengen met een leuk toestel en de eigenaar van het nummer komt er pas achter als hij eigenlijk denkt dat zn abo is afgelopen..
Gelegenheid maakt de dief. Ben benieuwd in hoeverre deze hack onofficieel bekent was.
Je kunt je moeilijk verweren als het misgaat en een bedrijf als vodafone beweert dat alles beveiligt is en dat je als noob maar moet aantonen dat je toch echt niet op de hoogte was.
Je kunt je moeilijk verweren als het misgaat en een bedrijf als vodafone beweert dat alles beveiligt is en dat je als noob maar moet aantonen dat je toch echt niet op de hoogte was.
Er is helemaal geen sprake van een hack.deze hack
En je kunt geen leestekens gebruiken... dus Enkel abc ABC en 123
Vond ik ook wel een security flaw.
Vond ik ook wel een security flaw.
Bij voicemail kan je alleen cijfers gebruiken, da's pas gevaarlijk...
Heb je al uitgerekend hoeveel mogelijkheden je hebt met 26+26+10 posities per karakter?
Heb je al uitgerekend hoeveel mogelijkheden je hebt met 26+26+10 posities per karakter?
56 800 235 584, als je uit gaat van 6 karakters.
Dus met andere woorden...
In combinatie met een spoof van de iOS-app en dit maakt het niet uit of ze er nu de wachtwoorden gaan versleutelen als de gebruiker zijn/haar wachtwoord niet wijzigd..
Hierop zou een flinke vergoeding moeten staan dit is beveiliging les 1 en zeker na de berichten van de afgelopen maanden..
De developers / managers / systeem-beheerders mogen wel eens wakker worden..
In combinatie met een spoof van de iOS-app en dit maakt het niet uit of ze er nu de wachtwoorden gaan versleutelen als de gebruiker zijn/haar wachtwoord niet wijzigd..
Hierop zou een flinke vergoeding moeten staan dit is beveiliging les 1 en zeker na de berichten van de afgelopen maanden..
De developers / managers / systeem-beheerders mogen wel eens wakker worden..
Uhm... het wachtwoord werd dan wel onversleuteld toegestuurd, maar dan wel per SMS. En dat is formeel een kanaal dat Vodafone volledig (kan) beheren - want zij zijn de telecom leverancier...
Ik weet het, het is een slap excuus, maar Vodafone houdt in zekere zin wel wat controle over het versturen van de wachtwoorden omdat het per SMS gaat, en niet per e-mail dus. SMS is nog vrij lastig af te luisteren: je moet dicht in de buurt zijn van je doelwit en deze laten communiceren met jouw GSM accesspoint.
En grootschalige hack met de iOS hack lijkt me dus niet mogelijk: alhoewel je de aanvraag voor een nieuw wachtwoord wellicht wel kan faken, zal dat nieuwe wachtwoord worden verstuurd naar de telefoons waar je nog geen controle over hebt.
Wat wel een kwalijke zaak is, is dat dus niet alleen LinkedIn, maar dus ook Vodafone niet de moeite neemt z'n wachtwoorden database te hashen. Hoe lui kan je zijn?
Ik weet het, het is een slap excuus, maar Vodafone houdt in zekere zin wel wat controle over het versturen van de wachtwoorden omdat het per SMS gaat, en niet per e-mail dus. SMS is nog vrij lastig af te luisteren: je moet dicht in de buurt zijn van je doelwit en deze laten communiceren met jouw GSM accesspoint.
En grootschalige hack met de iOS hack lijkt me dus niet mogelijk: alhoewel je de aanvraag voor een nieuw wachtwoord wellicht wel kan faken, zal dat nieuwe wachtwoord worden verstuurd naar de telefoons waar je nog geen controle over hebt.
Wat wel een kwalijke zaak is, is dat dus niet alleen LinkedIn, maar dus ook Vodafone niet de moeite neemt z'n wachtwoorden database te hashen. Hoe lui kan je zijn?
GSM is in theorie af te luisteren. Handig daarbij is dat je meestal een paar kilometer verderop nog kunt meeluisteren. Enkel via 3G is het nog redelijk veilig...
Zo ken ik er nog een: bij je Pathe account geldt dit ook.
Tjonge jonge zeg. De zoveelste smet op hun blazoen waardoor ik zeer ernstig nadenk over vertrek bij Vodafone.
Bij kruidvat was mn moeder laatst haar wachtwoord kwijt. Toen kreeg ze hem ook in plaintext opgestuurd via email.
Ik heb de helpdesk gemailt en 2 week later kreeg ik bericht dat het probleem gefixt was.
Ik heb de helpdesk gemailt en 2 week later kreeg ik bericht dat het probleem gefixt was.
Of het ook daadwerkelijk intern is gefixt of dat ze slechts enkel niet meer de wachtwoorden verzenden weet ik niet.wij begrijpen uw melding en hebben dit ook vanaf vandaag aangepast mede door de u aangegeven redenen. onze excuses voor het ongemak.
[Reactie gewijzigd door NE5Freak op vrijdag 29 juni 2012 15:59]
Ik heb dat maanden geleden al aangekaart bij de helpdesk (zelfde situatie), toen is er niks mee gedaan.
Even gecheckt, nu hebben ze er eindelijk wel iets aan gedaan.
Ook bij de webshop van Pro gamestore worden wachtwoorden onversleuteld opgeslagen.
Is dit iedere keer een tip aan tweakers.net waard?
Misschien interessant om eens een rondgang te doen bij de webshops in de pricewatch om te kijken in hoeverre dit goed geregeld is. Ik denk dat het nog behoorlijk tegen zal vallen.
Even gecheckt, nu hebben ze er eindelijk wel iets aan gedaan.
Ook bij de webshop van Pro gamestore worden wachtwoorden onversleuteld opgeslagen.
Is dit iedere keer een tip aan tweakers.net waard?
Misschien interessant om eens een rondgang te doen bij de webshops in de pricewatch om te kijken in hoeverre dit goed geregeld is. Ik denk dat het nog behoorlijk tegen zal vallen.
[Reactie gewijzigd door Skizzik0 op vrijdag 29 juni 2012 16:06]
Ik vind dat er een waarschuwing moet komen.
"PAS OP! Deze shop slaat de wachtwoorden PLAINTEXT op!!!!"
"PAS OP! Deze shop slaat de wachtwoorden PLAINTEXT op!!!!"
Jazeker. Slechte PR lijkt vooralsnog de enige beweegredenen om fatsoenlijke security te implementeren. Tweakers heeft tegenwoordig een redelijk groot en breed publiek, dus daar wordt het management niet blij vanIs dit iedere keer een tip aan tweakers.net waard?
Als dit soort falen eenmaal naar buiten komt, dan is het allemaal ineens snel geregeld. Laten we hopen dat het concurrenten ook aanzet tot het gebruik van encryptie op gevoelige data. Het zou de normaalste zaak van de wereld moeten zijn en er zijn eigenlijk ook geen goede (economische) redenen om het niet te doen. Jammer dat het op deze manier moet alleen. Hopelijk leren ze het nog een keer.
Mij lijkt een encryptie toch wel het eerste waar je aan denkt als je ene login systeem schrijft, en bij een groot bedrijf als deze zou ik het tenminste ook nog salten, maarja, in ieder geval goed dat ze het nu alsnog gaan versleutelen.
Tja, dan bestaat er 'versleutelen' en versleutelen.
http://codahale.com/how-to-safely-store-a-password/
http://codahale.com/how-to-safely-store-a-password/
Het is een goede link die je post, maar versleutelen? De website die je aanhaalt gaat over het hashen, versleutelen impliceert dat het heen-en-weer kan terwijl dit bij hashen niet zo is.
Dit is een fundamenteel verschil.
Dit is een fundamenteel verschil.
[Reactie gewijzigd door Dronefang op vrijdag 29 juni 2012 16:30]
Hashen is onomkeerbaar. Er kan echter wel een key gegenereerd worden welke de zelfde hash tot resultaat heeft. En als dan bovendien er een standaardfunctie wordt gebruikt om de boel te hashen (zonder salt) dan is het simpelweg een kwestie van rainbowtabelletje erbij pakken en klaar zijn we.
Zo simpel is dat niet als je het artikel leest op de link. Met bcrypt en zijn work factor kun je niet snel zo'n tabel genereren.
Niet zo snel voor een grote database nee, maar wel voor de meest voorkomende wachtwoorden. Vandaar dat een goede salt ook altijd belangrijk is. Het voorbeeld zegt dat er 0.3 seconden nodig zijn om een wachtwoord te hashen. Stel je laat je pc een dag rekenen, dan heb je dus al een database met de 288000 meest voorkomende wachtwoorden.
(welke de meest voorkomende zijn kun je gewoon downloaden)
Hier nog een linkje over hoe je een goede salt maakt:
http://crackstation.net/hashing-security.htm
Als je specifiek 1 account wilt hacken is zoals het artikel wat dronefang aanhaalt een salt idd useless bij een bruteforce aanval. Een salt maakt aanvallen met 'Reverse Lookup Tables' waarbij simpelweg zoveel mogelijk accounts gelijktijdig gehackt moeten worden echter een stuk moeilijker.
(welke de meest voorkomende zijn kun je gewoon downloaden)
Hier nog een linkje over hoe je een goede salt maakt:
http://crackstation.net/hashing-security.htm
Als je specifiek 1 account wilt hacken is zoals het artikel wat dronefang aanhaalt een salt idd useless bij een bruteforce aanval. Een salt maakt aanvallen met 'Reverse Lookup Tables' waarbij simpelweg zoveel mogelijk accounts gelijktijdig gehackt moeten worden echter een stuk moeilijker.
[Reactie gewijzigd door NE5Freak op vrijdag 29 juni 2012 18:59]
Bcrypt genereert automagisch een salt, niet aan de orde dus.
@sgreehder
Als bcrypt automatisch een salt genereert. Hoe kom je er dan achter wat de salt is?
Elke keer dat een login systeem een wachtwoord laat hashen moet er de zelfde hash uitkomen. Voor 1 specifieke gebruiker moet dus steeds de zelfde salt gebruikt worden. Bcrypt zou dus (gegeven enkel het wachtwoord zonder verdere informatie, als je verdere informatie zou geven zou dat immers al een niet automatisch gegenereerde salt zijn ) steeds de zelfde salt moeten geven.
Als bcrypt dus automatisch een salt zou genereren, dan zou je dus gewoon weer lookup tables kunnen gebruiken. Immers voor elk wachtwoord is slechts één unieke salt mogelijk. Welke bcrypt dan meteen aan een hacker zou geven. Dus dan zouden lookup tables weer gewoon mogelijk zijn.
Als bcrypt automatisch een salt genereert. Hoe kom je er dan achter wat de salt is?
Elke keer dat een login systeem een wachtwoord laat hashen moet er de zelfde hash uitkomen. Voor 1 specifieke gebruiker moet dus steeds de zelfde salt gebruikt worden. Bcrypt zou dus (gegeven enkel het wachtwoord zonder verdere informatie, als je verdere informatie zou geven zou dat immers al een niet automatisch gegenereerde salt zijn
) steeds de zelfde salt moeten geven.Als bcrypt dus automatisch een salt zou genereren, dan zou je dus gewoon weer lookup tables kunnen gebruiken. Immers voor elk wachtwoord is slechts één unieke salt mogelijk. Welke bcrypt dan meteen aan een hacker zou geven. Dus dan zouden lookup tables weer gewoon mogelijk zijn.
Dus met een lange salt en bcrypt zit je waarschijnlijk het veiligst.
Salt wordt meegegeven in de hash, zo ook de workfactor. We spreken weer zodra quantum computing voor de deur staat, tot die tijd is bcrypt of kompanen het minimum.
Nope, dat is het niet, zelfs semantisch niet. Of je nu hasht (one-way) of codeert (two-way), het blijft versleutelen (onleesbaar maken). Bovendien gaat het om dezelfde algoritmes.Het is een goede link die je post, maar versleutelen? De website die je aanhaalt gaat over het hashen, versleutelen impliceert dat het heen-en-weer kan terwijl dit bij hashen niet zo is.
Dit is een fundamenteel verschil.
Het ligt in de definitie van versleutelen en die is toch echt - volgens Wikipedia weliswaar - het volgende:
Hier staat duidelijk dat het ook gaat om het onleesbaar maken, wat jij ook vertelt, maar tegelijkertijd dat het ook leesbaar moet kunnen worden gemaakt. Dit kan je van hashen niet zeggen.
Bron: http://en.wikipedia.org/wiki/EncryptionIn cryptography, encryption is the process of transforming information (referred to as plaintext) using an algorithm (called a cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key. The result of the process is encrypted information (in cryptography, referred to as ciphertext). The reverse process, i.e., to make the encrypted information readable again, is referred to as decryption (i.e., to make it unencrypted).
Hier staat duidelijk dat het ook gaat om het onleesbaar maken, wat jij ook vertelt, maar tegelijkertijd dat het ook leesbaar moet kunnen worden gemaakt. Dit kan je van hashen niet zeggen.
Hashen is dan ook precies dat je wilt doen voor passwords. Die zouden nooit encrypted opgeslagen moeten worden, onder geen beding. Dan kan iemand die de encryption key achterhaalt ook alle wachtwoorden achterhalen. Bij hashen lukt dit alleen als het hele slechte wachtwoorden zijn, en/of een hele slechte hash-functie.
Ik viel laatst al bijna van mijn stoel toen ik een andere applicatie moest converteren naar ons pakket, en alle wachtwoorden plain text opgeslagen waren. Blijkbaar is dat dus normaal! Developers, developers....
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
