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)

[hellbringer]

Tja dat zijn er wel meer: Ziggo bijvoorbeeld

Mailtjes bij activatie:

Gefeliciteerd! Je hebt alle stappen succesvol afgerond en je bent nu online.
Wij wensen je veel plezier en gemak met de producten van Ziggo. De volgende instellingen zijn opgeslagen:

Een mijnZiggo account met
gebruikersnaam: <accountnaam> en wachtwoord <ingesteld wachtwoord>
Een email account met
E-mailadres: <emailadres> en wachtwoord <ingesteld wachtwoord>

en bij wijzigen van je wachtwoord:

Je hebt op ziggo.nl je wachtwoord voor Mijn Ziggo gewijzigd. Hieronder volgen je nieuwe inloggegevens voor Mijn Ziggo.

Gebruikersnaam: <accountnaam>
Wachtwoord: <ingesteld wachtwoord>

Gebruik deze gegevens om in te loggen op mijn.ziggo.nl.

Bij het aanpassen van je wachtwoord op mijnZiggo:

Het wachtwoord (minimaal 5 en maximaal 16 karakters) mag bestaan uit:
cijfers, kleine en/of hoofdletters en de volgende tekens: spatie . , & ( ) : ; - _

WTF zijn dit voor eisen aan een wachtwoord?! En daarnaast zo'n stom balkje met 'Zo veilig is uw wachtwoord' (plaatje)

MIJN WACHTWOORD IS HELEMAAL NIET VEILIG ALS JULLIE HET ONVERSLEUTELD OPSLAAN!

[Kagelol]

Als je waarschuwingen over welke webshop plaintext heeft dan hebben de hackers een mooi lijstje om af te gaan.

overigens heb ik net mijn wachtwoord van tweakers gereset, en ik kreeg hem ook in plaintext opgestuurd via de email.

[Anoniem: 159816]

Dat is een tijdelijk wachtwoord dat automatisch wordt gegenereerd. Ik durf er vergif op in te nemen dat los van dat mailtje nergens dat tijdelijk wachtwoord plain-text is opgeslagen.

[Kagelol]

Nadat ik deze gereset hebt moest ik NIET direct mijn wachtwoord veranderen (heb zelf zitten zoeken waar dat zit hier ) en er staat in de mail niets over dat dit wachtwoord tijdelijk is. je moet het wachtwoord alleen activeren d.m.v. een link te klikken.

[Anoniem: 159816]

Dan hoeft het nog steeds niet onveilig te zijn.

[expor]

Dat is toch wel iets anders. Bij het aanmaken van een wachtwoord kan de ingevulde waarde (in het tekstveld is het immers gewoon een plain-text waarde) direct worden uitgelezen. Deze waarde wordt in een mail naar jou gestuurd voordat deze in de database wordt versleuteld en opgeslagen.

Dan is er uiteraard de vraag of mails worden opgeslagen

[Kagelol]

Allemaal waar, ik probeer er meestal maar niet over na te denken.
als je er teveel over nadenkt begin je pas echt bang te worden van het internet .....

en uit eindelijk, zelfs als het geëncrypt is .. als de "hackers" het echt graag willen hebben dan bouwen ze wel een decrypter..

[Reactie gewijzigd door Kagelol op 22 juli 2024 15:47]

[sewer]

Dat had ik een keer bij een bank (waarschijnlijk ATB-bank), 5x verkeerd wachtwoord ingetikt zodat mijn account vergrendeld was. Nadat ik contact had opgenomen zouden ze me een brief sturen, staat daar gewoon mijn verzonnen wachtwoord in.

Was ook wel een WTF-momentje.

[TvdW]

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?"

[Niemand_Anders]

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.

[CyBeRSPiN]

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.

Dan resetten ze toch naar een wachtwoord dat ze dan telefonisch doorgeven dat je als klant bij 1e inlog moet aanpassen?
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..)

[Jasper Janssen]

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.

[RobIII]

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.

[Ethikka]

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)

[De_Delph]

Of natuurlijk via SMS...

[GuardMoony]

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.

[roy-t]

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.

[Jasper Janssen]

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.

[robvanwijk]

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 moet ook niet een salt per bedrijf hebben, je moet een salt hebben per user...

[KiLLerS]

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.

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.

En inderdaad, alle legacy systemen die geen password encryptie ondersteunen, behoren aan een aparte database te hangen, zodat ook deze gevoeligheid dichtgetimmerd is.

[Heineken]

Alle wachtwoorden bij Telfort staan ook onversleuteld in de database...

[Anoniem: 143916]

Klopt, telfort helpdesk medewerkers kunnen je wachtwoord gewoon zien

[wizkid_niels]

Bij XMS ook. Ze mochten het wachtwoord niet afgeven maar konden het wel inzien.

[spookz0r]

Bij UPC alleen het wachtwoord voor de e-mail mits de klant deze niet verandert. Als deze veranderd is kan UPC geen wachtwoorden inzien

[Anoniem: 58485]

T-mobile kan ook aan het lijstje worden toegevoegd. Die sturen het per SMS onversleuteld.

[Creesch]

@ 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.

[Reactie gewijzigd door Creesch op 22 juli 2024 15:47]

[Anoniem: 295912]

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.

[Reactie gewijzigd door Anoniem: 295912 op 22 juli 2024 15:47]

[Loekie]

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.

[hackerhater]

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

[Cocytus]

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.

[Reactie gewijzigd door Cocytus op 22 juli 2024 15:47]

[Cpt Placeholder]

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.

[WebHawk]

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 22 juli 2024 15:47]

[Anoniem: 415735]

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.

[The Reeferman]

Mijn God, hebben ze dan niks geleerd de afgelopen tijd.

[Vihaio]

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.

[Reactie gewijzigd door Vihaio op 22 juli 2024 15:47]

[Shamalamadindon]

Elke helpdesk in een bedrijf kan wachtwoorden resetten, betekent niet dat ze die ook kunnen inzien

[Yucko]

als men bij de helpdesk je wachtwoord kan lezen, dan zou men die gewoon geven ipv te resetten

[Anoniem: 411917]

tenzij ze niet willen dat je weet dat ze het kunnen inzien (voorkomt discussie)

[robvanwijk]

Krijg je dan niet meteen te neiging om je password te veranderen in "WelkeIdiootSlaatIn2012WachwoordenNogOnversleuteldOp"...?

[Jasper Janssen]

"...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.

[Stoney3K]

"...MetEenMaximumLengteVan8Karakters"... Password too long.

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.

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.

[dwilmer]

Al is "correct horse battery staple" inmiddels vrij bekend - en dus onveilig, maar dat terzijde. Met andere woirden klopt het wel.

[coldasice]

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....

[Jasper Janssen]

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.

[Anoniem: 239824]

Zal je misschien niet lukken, password meer dan 16 tekens?

[White_Collar]

Niet waar, ze konden alleen de wachtwoorden resetten naar een wachtwoord in de brief, inzien was niet mogelijk

[Anoniem: 442878]

Klopt, telfort helpdesk medewerkers kunnen je wachtwoord gewoon zien

Inderdaad. Telfort "flikt" het ook.
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

[Anoniem: 159816]

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?

[Anoniem: 279971]

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.

[itarix]

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.

[moorscode]

Dan kunnen ze nog wel versleuteld in de database staan, alleen niet als hash maar als volledige encryptie.

[dexonic]

Voeg Ben dan ook aan die lijst toe.
Bij wachtwoord vergeten krijg je die ook netjes in plaintext terug

[Anoniem: 116717]

Bij het Financieel Dagblad werd mij zelfs gevraag is **** uw wachtwoord?

[Websmurf]

Een grote mobiele payment provider gooit username & password gewoon onversleuteld in de adresbalk als je een factuur probeert te downloaden... ook niet echt handig..

[webfreakz.nl]

Datzelfde geldt voor de database van Holland Heineken House.

[Sinus_rhythm]

Dan belde ik wel toevallig voor gelijk m'n abonnement op te zeggen..

[Rockvee2]

Dan kan je je wel afmelden voor internet, tv en alle online diensten .

[oliveroms]

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.

[NESFreak]

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.

wij begrijpen uw melding en hebben dit ook vanaf vandaag aangepast mede door de u aangegeven redenen. onze excuses voor het ongemak.

Of het ook daadwerkelijk intern is gefixt of dat ze slechts enkel niet meer de wachtwoorden verzenden weet ik niet.

[Reactie gewijzigd door NESFreak op 22 juli 2024 15:47]

[Skizzik0]

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.

[Reactie gewijzigd door Skizzik0 op 22 juli 2024 15:47]

[Mattie112]

Ik vind dat er een waarschuwing moet komen.

"PAS OP! Deze shop slaat de wachtwoorden PLAINTEXT op!!!!"

[Pb Pomper]

Is dit iedere keer een tip aan tweakers.net waard?

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 van
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.

[Anoniem: 431088]

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.

[Sgreehder]

Tja, dan bestaat er 'versleutelen' en versleutelen.

http://codahale.com/how-to-safely-store-a-password/

[Junketsu]

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.

[Reactie gewijzigd door Junketsu op 22 juli 2024 15:47]

[NESFreak]

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.

[Arietje]

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.

[NESFreak]

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.

[Reactie gewijzigd door NESFreak op 22 juli 2024 15:47]

[Sgreehder]

Bcrypt genereert automagisch een salt, niet aan de orde dus.

[NESFreak]

@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.

[Arietje]

Dus met een lange salt en bcrypt zit je waarschijnlijk het veiligst.

[Sgreehder]

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.

[Sgreehder]

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.

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.

[Junketsu]

Het ligt in de definitie van versleutelen en die is toch echt - volgens Wikipedia weliswaar - het volgende:

In 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).

Bron: http://en.wikipedia.org/wiki/Encryption

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.

[Ravek]

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.

[Anoniem: 160587]

Ik vind dat veel mensen voorbarige conclusies trekken waaronder tweakers.net zelf
Eentje waar ik me aan stoor is: "Als ze het kunnen mailen dan staat het in plaintext"

Ondanks dat ik het zelf ook een kwalijke zaak vind zijn er wel degelijk mogelijkheden waardoor je mensen plaintext wachtwoorden kunt e-mailen (wat niet slim is maar dat terzijde) maar ze toch versleutelt opslaat in de DB.

Encryption / Decryption met een key anyone?
Als ze de key dan goed veiligstellen (en dat kan) kan iemand jouw DB jatten maar zullen de wachtwoorden toch niet plaintext beschikbaar zijn.

Ik zie niet dat vodafone ergens zegt dat ze onversleuteld de wachtwoorden opslaan, dit is een (voorbarige) conclusie die getrokken word op basis van té weinig informatie in mijn ogen.

Hoe dan ook, goede ontwikkeling dat Vodafone dit gaat oplossen. Volledige versleuteling is altijd beter.

[Reactie gewijzigd door Anoniem: 160587 op 22 juli 2024 15:47]

[DennusB]

Dat heet salten. En ja, als het omkeerbaar is is het net zo onveilig als onversleuteld

[Anoniem: 160587]

Om het hard te zeggen, nee en je conclusie is dan ook redelijk kortzichtig.

Je hebt bij encryptie altijd een key, en als je de key veilig houdt dan kan je database mooi versleutelt zijn maar kan je mensen wel hun decrypted "stuff" terug geven.

Is het onveilig? Ja.
is het net zo onveilig als onversleuteld? Nee.
Kan het veiliger? Ja.

[Reactie gewijzigd door Anoniem: 160587 op 22 juli 2024 15:47]

[Anoniem: 464735]

Dat was ook mijn eerste gedachte. Een wachtwoord kán ook met sterke encryptie zijn opgeslagen en is daardoor alleen te bekijken als je over de sleutel(s) beschikt. Beter is om te hashen (met salt), zodat het alleen omkeerbaar is als je beschikt over opgeslagen hashes ofwel rainbow tables.

Het feit dat iemand zijn wachtwoord in plain tekst te zien krijgt per sms, hoeft niet te betekenen dat een wachtwoord niet veilig is opgeslagen.
Of het een goed idee is om iemand een plain text wachtwoord toe te sturen (per mail of sms of wat dan ook), is een ander vraagstuk.

[Reactie gewijzigd door Anoniem: 464735 op 22 juli 2024 15:47]

[Anoniem: 160587]

Ben het met je eens, maar ik verwachtte wel iets meer niveau van tweakers.net met dit soort conclusies.

Vooral als je dan als titel van je post
"Vodafone versleutelt wachtwoorden van klanten niet" geeft.

Enfin, ik ga me er niet verder druk over maken .

[Tukkertje-RaH]

Encryption / Decryption met een key anyone?
Als ze de key dan goed veiligstellen (en dat kan) kan iemand jouw DB jatten maar zullen de wachtwoorden toch niet plaintext beschikbaar zijn.


Ergens moet een applicatie die key hebben om jou automagisch je wachtwoord toe te sturen. Ergens in de code moet dat wachtwoord dus staan. Als een applicatie er bij kan, kan een hacker er ook bij...

Een hash (en dan liefst SHA-512 ipv het oude MD5!!) lost dit probleem vrijwel volledig op. Je table met user/pass is minder gevoelig geworden, en als het hashing mechanisme goed is kan een hacker er nagenoeg niets mee. Het is ook goedkoop te implementeren. Veel goedkoper dan een symmetrisch versleutelde database waar je wachtwoorden in opslaat...

[Orion84]

"Als een applicatie er bij kan, kan een hacker er ook bij" is wel heel kort door de bocht.

Er zijn grote commerciële Identity Management producten die symmetrische encryptie ondersteunen om het wachtwoord op te slaan. Waarbij de keyfile afgeschermd op het filesystem (en in het geheugen staat).

Dat kan wel degelijk nuttig zijn. Bijvoorbeeld voor doeleinden zoals klantvriendelijk iemand zijn wachtwoord kunnen mededelen (bij voorkeur zonder tussenkomst van een persoon natuurlijk), maar ook om het makkelijker te maken om wachtwoorden te synchroniseren tussen verschillende directories, die niet dezelfde hashing ondersteunen.

De applicatie die via het internet te bereiken is kan dan nergens bij, behalve bij een LDAP interface van die identity of access manager. Dan moet je als hacker wel een aardig eindje verder doordringen dan een simpele SQL injectie op de database van de webapplicatie

Ik ben het dus wel eens met wat sommigen hier opmerken: dat een bedrijf je je eigen gekozen wachtwoord kan toesturen is niet per definitie bewijs dat ze de boel onveilig opgeslagen hebben.

Maar regelmatig zal dat inderdaad wel het geval zijn en als iedere helpdeskmedewerker zomaar wachtwoorden zelf kan inzien is dat in elk geval zeker geen goed teken.

[Remenic]

Dat werkt ook alleen maar als de key niet op de database server staat. En ik vermoed dat als ze je webserver hacken, waar die key waarschijnlijk op staat, het een koud kunstje zal zijn om die key even lokaal op te slaan, database kopie te maken, om vervolgens op je dooie gemakje lekker los te gaan met de data.

Maar de ontwikkelaar slaapt tenminste zacht, want die denkt het allemaal goed gedaan te hebben.

Volgens mij is de 'enige goede' manier van wachtwoorden opslaan door te hashen. Dan kun je nooit het originele wachtwoord afleiden. In het ergste geval zijn er variaties die eventueel toevallig dezelfde hash als resultaat hebben, maar die kans is erg klein.

[Ajunne]

Ik vraag me af of onze vriend DennusB al over zijn flikker heeft gekregen van zijn baas, die een grote leverancier voor Vodafone is. Je kunt dit soort dingen natuurlijk ook onderwater regelen voordat je ze aan de grote klok hangt, zeker als Vodafone uiteindelijk jouw salaris betaalt...

[cire]

Zo makkelijk is het niet om dit onder water te regelen.

Hoe los je dan namelijk de use case op: "klant is zijn wachtwoord vergeten en wil het graag terugkrijgen".

Ik bedoel: het heeft iets meer impact dan alleen de IT afdeling.

[OddesE]

Tijdelijk wachtwoord maken (nieuw) dat een dag geldig is en opsturen naar de klant, die kan dan daarmee inloggen en moet dan meteen een nieuw wachtwoord kiezen. Dit is toch standaard bij goede sites?

[Anoniem: 412416]

Klant een e-mail sturen met een unieke link (lees: hash) waarmee hij zijn wachtwoord eenmalig kan wijzigen.

Dit is de tweede keer in dit topic dat je een aanname doet die geen hout snijdt, probeer je eens in te lezen in het beveiligen van web-applicaties alvorens te stellen wat wel of niet mogelijk is.

[Anoniem: 20901]

Het is wel fijn als je gewoon je wachtwoord terugkrijgt ipv steeds een ander te moeten maken....

[Coocoocachoo]

Wat is daar dan zo fijn aan? Als je hetzelfde wachtwoord wilt kan je die daarna gewoon weer intypen. En als je hem toch vergeten was, waarom zou je hem dan willen houden?

[AlBundy]

Bij je Google account mag je niet je paar (weet ff niet hoeveel) laatstgebruikte wachtwoorden gebruiken

[Dysmael]

Dat is niet waar. De enige eis is dat het wachtwoord uit minimaal 8 karakters bestaat. Bij Google Apps kan door de beheerder andere eisen aan het wachtwoord worden gesteld.

[DennusB]

En als je account dan een week later overhoop getrokken word door wat 'hackers' denk je wel anders....

[Anoniem: 26447]

De bekende dooddoener, ALS, als de lucht valt hebben wij allemaal een blauwe hoed op (als het zonnig is, anders een grijze) Er is eigenlijk 1 hele simpele reden dat wachtwoorden plain worden opgeslagen, dat is het goedkoopst !!!!!!!! alle sleutel werk kost geld op de 1 of andere manier, de bedoeling is om geld te ontvangen en niet om geld uit te geven. Simpele economische wet.

[AlBundy]

Hoe fijn het ook is, het is enorm onwenselijk. Als het uitlekt ligt je wachtwoord op straat. Niet voor iedereen een probleem, maar genoeg mensen die hetzelfde wachtwoord voor meerdere diensten gebruiken.

[Gropah]

Het is misschien wel fijn, maar het is minder veilig. Daarnaast moet je het ook zo bekijken: Als je je wachtwoord niet meer weet, dan is het blijkbaar niet makkelijk te onthouden (of is het je standaard wachtwoord niet meer) en kun je het dus net zo goed meteen vervangen. Hoe je niet elke keer dat je daar probeert in te loggen weer een mail te krijgen met daarin je wachtwoord wat gewoon een gevaar voor de beveiliging is.

[Anoniem: 367168]

Daarvoor hebben ze de geheime vragen gemaakt, waar alleen jij het antwoord op weet.

[Remenic]

Ik weet niet of je sarcastisch was, maar bij veel sites waar je zo'n 'geheime vraag' kunt invullen, heb je slechts een beperkt keuze uit voorgedefinieerde vragen, en in mijn vriendenkring + familie is er altijd wel minimaal 1 die het antwoord weet.

Die geheime vragen zijn juist bedacht om 'hackers' een handje te helpen, niet om de gebruiker een plezier te doen.

[Xyrr]

Het is dan ook handig om een twist te geven aan het antwoord dat je geeft. Je zou bijvoorbeeld altijd hetzelfde antwoord kunnen gebruiken, ondanks dat dit niet aansluit op de vraag. Een betere manier is nog om als antwoord op de vraag "je eerste huisdier" niet direct "knabbel" in te vullen maar "knabbelhetkonijn". Als je dat consistent vol houdt weet je zelf altijd hey antwoord, en typen familieleden/vrienden ondanks dat ze het antwoord weten het niet juist in.

[Reactie gewijzigd door Xyrr op 22 juli 2024 15:47]

[ThomasG]

Wat ik frapant vind is dat iedereen er blindelings vanuit gaat dat de wachtwoorden plaintekst in de database staan. Het zou ook kunnen dat deze versleuteld zijn ipv gehasht, dan zijn de wachtwoorden dus nog terug te halen mits je het algoritme en de geheime sleutel weet. Bij een database dump heb je er dan nog steeds niet zoveel aan.

[OddesE]

Maar waarom zou je, als je toch geld uit gaat geven aan beveiliging en encryptie, ervoor kiezen om een duurdere en ingewikkeldere methode toe te passen dan hashing?

Immers waar laat je de decryption key? Ook in die database? In een andere database? Die dan op een andere server staat? Ingewikkeld allemaal. Een heel stuk lastiger dan wachtwoorden gewoon hashen en een pasword reset functie in te bouwen.

Het is dus gewoon verreweg het meest voor de hand liggend dat men überhaupt geen geld of tijd heeft uitgegeven aan beveiliging en dat de wachtwoorden gewoon helemaal niet versleuteld zijn.

[90710]

De key zou idd op bv een geïsoleerde server op het interne netwerk kunnen staan. En als ze dan een beetje netjes zijn maken ze een key per gebruiker. Zolang deze server enkel intern bereikbaar is is er niets aan de hand. (Tenzij dit fysiek gehacked gaat worden)

Dat het niet de makkelijkste oplossing is, is duidelijk. Maar het kan wel een praktische zijn.

[jochem4207]

Is die versleuteling dan wel veilig?

[Anoniem: 204567]

Dat is net zo fout. Wachtwoorden moeten gewoon NIET worden opgeslagen, nooit. Is ook nergens voor nodig.

(behalve natuurlijk wachtwoorden van accounts waar je zelf mee moet inloggen, maar dan fungeer je als gebruiker, niet als aanbieder/accountbeheerder)