O'Reilly reset mijn password en stuurt hem plaintext

[armageddon_2k1]

Ik heb een subscription bij SafariBooks van O'Reilly en had een hoop problemen met de app en heb ze een mail gestuurd, nu krijg ik vanochtend het volgende:

Hi armageddon_2k1,

Thank you for reaching out. I'm sorry for the inconvenience. I have reset your password to troubleshoot the issue, and have resolved the problem. I was able to sign in to the O'Reilly app with your email and password: [knip]Iets heel korts, bijna zoiets als welcome123[/knip]

If you have any other questions, or concerns, please let me know.

Best regards,

Tami | Customer Service

Even afgezien van het feit dat het nogal lomp is zo te doen staan er allemaal vertrouwelijke dingen in mijn account die ik in moest vullen. Zoals, mijn creditcard gegevens en mijn adresgegevens. Ik ben dus, begrijpelijk niet heel erg amused, maar vraag me af of er hier geen juridische grenzen overschreden worden? Het is een amerikaans bedrijf, maar dan nog vraag ik me af of ik het ergens moet melden?

[ImNotnoa]

Je kunt ze in ieder geval op de schandpaal nagelen: https://plaintextoffenders.com/

Of er een (US) overheidsinstantie is waar je zoiets kunt melden, geen idee eigenlijk.

Ik zou iig meteen een verzoek versturen naar die website om AL je gegevens te verwijderen aangezien ze niet in staat zijn deze op een veilige manier te bewaren

[F_J_K]

Je zou (ondanks dat het een US bedrijf is) je kunnen beroepen op de GDPR, bij hun Britse (!) data security manager melden dat dit een data breach is. Wijs ze er op dat ze in hun privacy policy beweren to transmit sensitive data using standard security protocols and mechanisms (such as secure socket layer (SSL) [sic!] encryption)
Of het veel uit gaat halen is maar de vraag.

armageddon_2k1 schreef op dinsdag 30 juni 2020 @ 08:08:
Zoals, mijn creditcardgegevens.

Check of ze zouden moeten voldoen aan PA-DSS. Dan zou cardholder data transmission versleuteld moeten gebeuren namelijk.

Edit: al kan het natuurlijk zijn dat een dergelijk password werkt zoals een tijdelijke passwordvergeetlink. Kan zijn dat een opgestuurd password eenmalig kan worden gebruikt en misschien ook wel maar tijdelijk werkt. Zoals ook een wachtwoordvergeet-link kan werken dat ook maar slechts een stel karakters op een rij is.

[ Voor 19% gewijzigd door F_J_K op 30-06-2020 09:15 ]

[delphium]

Hoe had je graag gezien dat ze het hadden opgelost?

[job]

delphium schreef op vrijdag 3 juli 2020 @ 10:16:
Hoe had je graag gezien dat ze het hadden opgelost?

Een wachtwoord reset-link lijkt me handiger.

[delphium]

Maar als ik die e-mail onderschep, zit ik ook in zijn account.

[Compizfox]

delphium schreef op vrijdag 3 juli 2020 @ 10:16:
Hoe had je graag gezien dat ze het hadden opgelost?

Wachtwoorden gehasht opslaan en reset-links gebruiken als de gebruiker zijn/haar wachtwoord is vergeten.

Het is echt een big no-no om wachtwoorden in plaintext op te slaan in een database.

[SinergyX]

job schreef op vrijdag 3 juli 2020 @ 10:18:
[...]

Een wachtwoord reset-link lijkt me handiger.

Handiger precie hoe? Mail onderscheppen maakt het geen kloot uit of dit plaintext of een URL is, beide kan ik dus prima zijn account pakken.

Daarbij een compleet aparte website draaien enkel voor afwikkeling van wachtwoord resets (zover ik weet draait die Oreilly enkel via de app, ook registeren),

Compizfox schreef op vrijdag 3 juli 2020 @ 10:22:
[...]

Wachtwoorden gehasht opslaan en reset-links gebruiken als de gebruiker zijn/haar wachtwoord is vergeten.

Het is echt een big no-no om wachtwoorden in plaintext op te slaan in een database.

Nu doe je een aanname die je niet hard kan maken, niets zegt dat die wachtwoorden ook zo worden opgeslagen, uitsluitend zo naar hem zijn gestuurd. Ik kan jou prima een wachtwoord sturen, deze daarna door het systeem met de hoogst mogelijke encryptie opslaan.

[delphium]

Wachtwoorden gehasht opslaan en reset-links gebruiken als de gebruiker zijn/haar wachtwoord is vergeten.

Het is echt een big no-no om wachtwoorden in plaintext op te slaan in een database.

Dat is hier helemaal niet aan de orde, of dat weten we in elk geval niet. Het wachtwoord is gereset door de beheerder en doorgestuurd naar de klant. Dat zegt niets over hoe ze worden opgeslagen in de DB.

[Compizfox]

SinergyX schreef op vrijdag 3 juli 2020 @ 10:23:
[...]
Nu doe je een aanname die je niet hard kan maken, niets zegt dat die wachtwoorden ook zo worden opgeslagen, uitsluitend zo naar hem zijn gestuurd. Ik kan jou prima een wachtwoord sturen, deze daarna door het systeem met de hoogst mogelijke encryptie opslaan.

Ah, iets te snel gelezen zie ik. Ik dacht dat ze TS' eigen wachtwoord (die ze dan dus wel plaintext moeten hebben opgeslagen) hadden opgestuurd.

[delphium]

Wat natuurlijk wel echt heel slecht is in dit specifieke geval is dat in de e-mail ook doodleuk wordt vermeld dat het wachtwoord is bedoeld voor de O'reilly app en dat waarschijnlijk (hopelijk niet!) het e-mailadres de gebruikersnaam is. Dat het wachtwoord plaintext is, hoeft echter geen probleem te zijn.

[armageddon_2k1]

Nee ze hebben mijn wachtwoord aangepast naar iets heel simpels en die me gewoon gemaild. De email is m’n login.

Ik heb nu contact met ze en het is niet de bedoeling iig. Als je als helpdesk al mee wil kijken in een account dan verwacht ik daarna een password reset link oid.

[delphium]

armageddon_2k1 schreef op vrijdag 3 juli 2020 @ 10:27:
Als je als helpdesk al mee wil kijken in een account dan verwacht ik daarna een password reset link oid.

Maar zoals gezegd, is dat niet veiliger dan een plaintext wachtwoord. Sterker nog; een wachtwoord heeft de voorkeur, mits het verstuurd wordt naar een alternatief e-mailadres en er in de e-mail verder geen details staan over waar het precies voor dient.

[Verwijderd]

Ik denk dat ik het juist erger zou vinden dat zij zelf in loggen op mijn account dan het versturen van een plaintext wachtwoord per mail.

[Room42]

delphium schreef op vrijdag 3 juli 2020 @ 10:31:
[...]


Maar zoals gezegd, is dat niet veiliger dan een plaintext wachtwoord. Sterker nog; een wachtwoord heeft de voorkeur, mits het verstuurd wordt naar een alternatief e-mailadres en er in de e-mail verder geen details staan over waar het precies voor dient.

Wat een onzin. Als het bedrijf een wachtwoord stuurt, is dat het wachtwoord. Veel gebruikers passen dat niet meer aan. Als je een reset-linkje krijgt, blijft het wachtwoord onbekend en moet de gebruiker zelf een wachtwoord kiezen.

Daarom stuur je een password reset link.

(Én tegenwoordig is het e-mailadres meestal ook de gebruikersnaam.)

[ Voor 5% gewijzigd door Room42 op 03-07-2020 10:49 ]

[F_J_K]

Room42 schreef op vrijdag 3 juli 2020 @ 10:48:
[...]

Wat een onzin. Als het bedrijf een wachtwoord stuurt, is dat het wachtwoord. Veel gebruikers passen dat niet meer aan.

Ik mag hopen (.....) dat een dergelijk gestuurd wachtwoord bij 1e keer inloggen verplicht moet worden aangepast naar iets sterkers. (Alleen) dan zijn reset links en passwords in de mail defacto gelijk.

[delphium]

Wat een onzin. Als het bedrijf een wachtwoord stuurt, is dat het wachtwoord. Veel gebruikers passen dat niet meer aan. Als je een reset-linkje krijgt, blijft het wachtwoord onbekend en moet de gebruiker zelf een wachtwoord kiezen.

Je kunt op veel systemen ook vereisen dat na de volgende inlog het wachtwoord moet worden aangepast. Dat is dus hetzelfde effect als een reset-link. Het probleem met de reset-link is dat het ook meteen het platform blootgeeft waar een nieuw wachtwoord voor is aangevraagd.

[Verwijderd]

Ik denk dat @armageddon_2k1 niet helemaal begrijpt waarom er altijd word gezegd dat plain-text wachtwoorden mailen een erg slecht idee is en wat de reden daarachter is:

Dit heeft betrekking op als je je wachtwoord kan opvragen (en dan letterlijk je eigen wachtwoord in je mail terug krijgt). Wat echt belachelijk is imo, ICT'ers die dat nog zonder extreem goede reden doen, mogen wat mij betreft gekruisigd worden

Daarbij is niet zozeer het feit dat je email makkelijk kan onderscheppen het probleem (want dat kan ook gewoon met een wachtwoord-reset-link) maar juist dat men jou eigen wachtwoord kan plain-text kan inzien. Dit komt omdat men de wachtwoorden dan niet met een fatsoenlijke hashing met salt in de database zet.

Dat staat los van het kunnen plain-text mailen van wachtwoorden. De wachtwoorden kunnen prima voor gehashed te worden op de mail gezet worden om vervolgens als hash met salt in de DB opgeslagen te worden.

Als je dit fatsoenlijk doet is het namelijk onmogelijk om het echte wachtwoord terug te halen.

Als je een wachtwoord reset kan dat met link of met een nieuw wachtwoord via mail. Dit laatste heeft niet de voorkeur (omdat je een link een bepaalde geldigheidsduur kan geven), maar als het systeem vervolgens forceert dat je je wachtwoord moet aanpassen na een eerste login (met dat toegestuurde wachtwoord), is er niks aan de hand.

Ook wachtwoord-reset links zijn niet heilig als je url niet random genoeg maakt; kortom beide manier zijn vrijwel gelijkwaardig als goed uitgevoerd.

[ Voor 12% gewijzigd door Verwijderd op 03-07-2020 11:12 ]

[Room42]

F_J_K schreef op vrijdag 3 juli 2020 @ 10:52:
[...]

Ik mag hopen (.....) dat een dergelijk gestuurd wachtwoord bij 1e keer inloggen verplicht moet worden aangepast naar iets sterkers. (Alleen) dan zijn reset links en passwords in de mail defacto gelijk.

delphium schreef op vrijdag 3 juli 2020 @ 10:52:
[...]


Je kunt op veel systemen ook vereisen dat na de volgende inlog het wachtwoord moet worden aangepast. Dat is dus hetzelfde effect als een reset-link. Het probleem met de reset-link is dat het ook meteen het platform blootgeeft waar een nieuw wachtwoord voor is aangevraagd.

Fair point, als echter aan al die voorwaarden voldaan wordt. Helaas zie je dit zelden. Het is makkelijk te achterhalen welke dienst de e-mail verstuurt en het eenmalig gebruik van een wachtwoord heeft dan inderdaad weinig meerwaarde t.o.v. een reset-link. Maar... Als wel aan die voorwaarden voldaan wordt, is dat inderdaad veiliger. Niet gebruikersvriendelijker maar wel veiliger (de bekende driehoek ).

[DukeBox]

Wat ik zo ook begrijp is dat het niet helemaal de standaard manier is maar nu zo gedaan is na interactie met de support desk. Sterker nog, als ik zo kijk hebben ze over het algemeen de beveiliging netjes op orde met ondersteuning van SSO waarbij 2FA mogelijk is.

Edit: Al lijkt safari books dat niet te ondersteunen (via een andere login) maar ook daar wordt een reset link verzonden bij het resetten met de normale manier.

[ Voor 23% gewijzigd door DukeBox op 03-07-2020 11:14 ]