Opslaan van klantwachtwoorden in password managers

Pagina: 1
Acties:

Vraag


Acties:
  • 0 Henk 'm!

  • Critycal
  • Registratie: December 2014
  • Laatst online: 25-10-2019
Hey, wist niet zo 123 waar ik dit kon posten dus ik hoopte het hier in de juiste categorie te hebben.

Ik werk voor een bedrijf dat o.a. WordPress sites maakt/beheert voor opdrachtgevers.
Nu is het zo dat er enige tijd geleden een account is geweest op 1 van de sites die een zwak wachtwoord had, en deze is gebruteforced.

Alles wat hieruit is ontstaan is direct verholpen, maar nu willen zowel mijn baas als de opdrachtgever een volledig overzicht van alle gebruikers, van alle sites, met daarbij alle wachtwoorden.

Wij gebruiken hier intern een passwordmanager met daarin alle accounts/wachtwoorden die wij zelf gebruiken.

Aangezien het voor mij vanuit een developersperspectief niet veilig/praktisch leek om (WordPress) klantenaccounts op te slaan in onze passwordmanager, heb ik altijd simpelweg de klanten;
A: een gegenereerd wachtwoord toegestuurd, vervolgens mail verwijderd.
B: een herstellink gestuurd met hierin de mogelijkheid voor de klant zelf om het wachtwoord aan te passen/genereren.

Omdat ik op deze manier werk heb ik dus geen plaintext overzicht met daarin alle wachtwoorden, per gebruiker, per site.
Dit kan ik dus ook niet aanleveren aan baas/klant.
Leek voor mij heel logisch om op deze manier enkel gehashte wachtwoorden op te slaan, mocht een klant het wachtwoord zijn vergeten is het namelijk net zo eenvoudig om ze een nieuw wachtwoord te laten genereren/invullen.

Echter ben ik nu hierdoor in de problemen gekomen en moet ik de klant precies uitleggen waarom ik op deze manier gewerkt heb, en waarom ik geen overzicht voor ze kan maken. Maar m'n baas zegt dus dat dit onverklaarbaar is.

Nu moet ik een mail opstellen waarin ik haarfijn uit moet leggen waarom ik dit niet aan kan leveren.
Zijn er hier toevallig mensen die hier wat meer over weten, zit ik inderdaad fout en moet ik de schuld hier op me nemen of zijn er regelgevingen waardoor ik juist op de juiste/veiligste manier gewerkt heb?

Hoor graag of iemand me kan helpen, zit nogal in de problemen hiermee en zou enorm helpen als er securitygoeroes zijn die me wat in de juiste richting kunnen helpen wat betreft m'n verklaring aan de klant.

Beste antwoord (via Critycal op 22-10-2019 17:04)


  • Stoelpoot
  • Registratie: September 2012
  • Niet online
2 redenen:

1. Je creëert een extra zwaktepunt waarbij de site kan worden aangevallen (jouw lijst).
2. Het is onmogelijk om de plaintext wachtwoorden in te zien vanwege het gebruik van standaard security-richtlijnen die aanbevolen worden door officiële instanties. Omdat gebruikers zelf hun wachtwoord kunnen aanpassen kan je ook niet verzekeren dat een door jou bijgehouden lijst actueel is, wat het nut van de lijst volledig teniet doet punt 1 dus nog vele malen gevaarlijker maakt (wel extra zwaktepunt zonder noemenswaardige voordelen).

Edit: Als toevoeging zit je ook nog met accountability. Wodpress houdt volgens mij bij wie welke aanpassing maakt. Als je de wachtwoorden van een klant kent kan je potentieel een werknemer van de klant impersoneren. Dat is misschien voor de klant geen goede reden qua vertrouwen, maar voor je baas wellicht wel als hij weet dat zijn medewerkers altijd te traceren zijn als ze klooien bij klanten.

[ Voor 26% gewijzigd door Stoelpoot op 22-10-2019 16:06 ]

Alle reacties


Acties:
  • Beste antwoord
  • +4 Henk 'm!

  • Stoelpoot
  • Registratie: September 2012
  • Niet online
2 redenen:

1. Je creëert een extra zwaktepunt waarbij de site kan worden aangevallen (jouw lijst).
2. Het is onmogelijk om de plaintext wachtwoorden in te zien vanwege het gebruik van standaard security-richtlijnen die aanbevolen worden door officiële instanties. Omdat gebruikers zelf hun wachtwoord kunnen aanpassen kan je ook niet verzekeren dat een door jou bijgehouden lijst actueel is, wat het nut van de lijst volledig teniet doet punt 1 dus nog vele malen gevaarlijker maakt (wel extra zwaktepunt zonder noemenswaardige voordelen).

Edit: Als toevoeging zit je ook nog met accountability. Wodpress houdt volgens mij bij wie welke aanpassing maakt. Als je de wachtwoorden van een klant kent kan je potentieel een werknemer van de klant impersoneren. Dat is misschien voor de klant geen goede reden qua vertrouwen, maar voor je baas wellicht wel als hij weet dat zijn medewerkers altijd te traceren zijn als ze klooien bij klanten.

[ Voor 26% gewijzigd door Stoelpoot op 22-10-2019 16:06 ]


Acties:
  • +3 Henk 'm!

  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

Waarom wil jouw baas alle wachtwoorden weten? Ik zou daar als klant niet blij mee zijn
Denk dat het logischer om (per site) een bedrijfsaccount voor jullie te maken, om in te grijpen als dat noodzakelijk is

QnJhaGlld2FoaWV3YQ==


Acties:
  • +1 Henk 'm!

  • F_J_K
  • Registratie: Juni 2001
  • Niet online

F_J_K

Moderator CSA/PB

Front verplichte underscores

De leverancier zou nooit de klantwachtwoorden mogen kunnen zien, dat is m.i. een groot beveiligingslek op zich. "Zelfs" bij MKB-klanten. Die zelfde wachtwoorden kunnen ook gebruikt worden bij andere diensten. Als je zelf toegang nodig hebt, maak een account voor jezelf naast die van de klant. Dan kan tenminste worden gelogd wat jij deed.

Wel kan je voortaan scriptmatig de "sterkte" checken en ook kan je achteraf in de DB algemene checks doen op veiligheid / "kraakbaarheid". Beter maak je brute forcen semi-onmogelijk door slechts 1 loginpoging per minuut toe te staan en te piepen als er meer dan een N pogingen komen.

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind' (Terry Pratchett, Eric)


Acties:
  • 0 Henk 'm!

  • Critycal
  • Registratie: December 2014
  • Laatst online: 25-10-2019
Brahiewahiewa schreef op dinsdag 22 oktober 2019 @ 16:06:
Waarom wil jouw baas alle wachtwoorden weten? Ik zou daar als klant niet blij mee zijn
Denk dat het logischer om (per site) een bedrijfsaccount voor jullie te maken, om in te grijpen als dat noodzakelijk is
Omdat hij dit moet aanleveren aan de klant, die nu, na de bruteforce, een overzicht wilt van alle gebruikers die in de sites kunnen (en het wachtwoord hiervan).
Ik heb ze een overzicht aangeleverd van alle gebruikers, exclusief wachtwoord. Deze willen ze dus erbij hebben nu.

Wij hebben bedrijfsaccounts, die staan allemaal in onze eigen passwordmanager. Die gebruiken wij ook intern.
Echter is de verwachting nu dat wij buitenom alle bedrijfsaccounts ook de wachtwoorden van klanten opslaan.
Dit lijkt mij niet logisch/veilig/praktisch, maar de klant/mijn baas begrijpt dit niet. Moet dit dus aan hen uitleggen.
Stoelpoot schreef op dinsdag 22 oktober 2019 @ 16:01:
2 redenen:

1. Je creëert een extra zwaktepunt waarbij de site kan worden aangevallen (jouw lijst).
2. Het is onmogelijk om de plaintext wachtwoorden in te zien vanwege het gebruik van standaard security-richtlijnen die aanbevolen worden door officiële instanties. Omdat gebruikers zelf hun wachtwoord kunnen aanpassen kan je ook niet verzekeren dat een door jou bijgehouden lijst actueel is, wat het nut van de lijst volledig teniet doet punt 1 dus nog vele malen gevaarlijker maakt (wel extra zwaktepunt zonder noemenswaardige voordelen).

Edit: Als toevoeging zit je ook nog met accountability. Wodpress houdt volgens mij bij wie welke aanpassing maakt. Als je de wachtwoorden van een klant kent kan je potentieel een werknemer van de klant impersoneren. Dat is misschien voor de klant geen goede reden qua vertrouwen, maar voor je baas wellicht wel als hij weet dat zijn medewerkers altijd te traceren zijn als ze klooien bij klanten.
Thanks. Ben momenteel een mail aan het opstellen waarin ik al deze punten verwerk.
Hoop dat er misschien iemand is die met wat meer wetgeving/AVG gerelateerde punten kan komen zodat ik dit verder hard kan maken aan de klant. Heb dit namelijk al uitgelegd aan m'n baas, maar die begrijpt de gedachtegang hierachter niet.

[ Voor 47% gewijzigd door Critycal op 22-10-2019 16:12 . Reden: aanvulling/voorkomen van doubleposting ]


Acties:
  • +1 Henk 'm!

  • DarkSide
  • Registratie: Oktober 2000
  • Laatst online: 13-10 21:32

DarkSide

theres no place like ::1

idd.
Je hebt als beheerder toegang tot je beheerde sites. Daar ben jij verantwoordelijk voor.
Je klanten hebben toegang tot hun eigen site met hun eigen wachtwoord

Ik zal als klant nooit willen dat iemand mijn wachtwoord weet en kan inzien.
En ik zou meteen weggaan als een externe partij zo omgaat met mijn wachtwoorden.

Daarbij hoort niemand het wachtwoord van een ander te weten.

Die klant moet ook even nadenken.
Hoe weet de klant wie er dan in een site is geweest als hij de wachtwoorden heeft.
En wat denkt hij te bereiken als wachtwoorden ergens anders opgeslagen worden.

straks wordt er een aanpassing gedaan met een account waarvan jij het wachtwoord weet.
Bewijs dan maar dat jij niet iets gedaan hebt.

There are 10 kinds of people in this world..... Those who know binary. And those who don't.


Acties:
  • +1 Henk 'm!

  • PatrickH89
  • Registratie: November 2009
  • Laatst online: 15:24
Hij moet niet de passwords aan kunnen leveren aan de klant aangezien deze niet opgeslagen worden in plain text en het ook een significant risico zou zijn om die wel op te slaan in plain text. Jij hebt juist gehandeld en er is geen enkele reden om die passwords te willen weten (om in te loggen als deze wachtwoorden er niet zijn bestaat er een reset mogelijkheid).

Als je een lijst hebt met plain text gelekte wachtwoorden die mogelijk gebruikt zijn kun je die hashen en vergelijken om te kijken of ze voorkomen (ik weet niet of dat een usecase is die je hier nodig hebt). Anders wachtwoorden resetten in geval van (mogelijk) misbruik.

Mocht je meer munitie nodig hebben dan zou ik een google sessie besteden aan 'why hash passwords' en dan zijn er legio hits die je waarschijnlijk beter kunnen uitleggen waarom dit moet.

[ Voor 12% gewijzigd door PatrickH89 op 22-10-2019 16:15 ]


Acties:
  • +2 Henk 'm!

  • Jaapio_B
  • Registratie: November 2001
  • Laatst online: 14:38
Zoals hier boven al een aantal keren is aangegeven het je met jou werkwijze juist gehandeld.

Het probleem is nu dus van je wordt verwacht dat je een lijst met alle inloggegevens, van alle websites die jullie in beheer hebben, moet aanleveren.
Dit is dus niet mogelijk en daar zal jouw baas genoegen mee moeten nemen.

Ik ben zelf niet echt bekend met Wordpress maar is het niet mogelijk voor alle accounts in te stellen dat ze alleen maar moeilijke wachtwoorden kunnen gebruiken en daarna alle accounts te blokkeren en nieuwe herstellinks toe te sturen.

Aan alles komt een eind.


Acties:
  • +1 Henk 'm!

Verwijderd

Klinkt als een paniekreactie van de klant. Wachtwoorden in plain text opslaan is een no-go - zoals hierboven al gezegd.

Ik zou het over een andere boeg gooien:

Jullie gaan als bedrijf dagelijks / wekelijks scannen of bekende wachtwoorden (databases zijn online te vinden) gebruikt worden. Idem voor eenvoudige. En de eisen bij het wijzigen van de wachtwoorden worden aangescherpt.

Het gaat in dit soort situaties er vooral om dat je de klant en je baas gerust stelt dat het geen tweede keer gebeurt. Het technische verhaal van hoe of wat is van secundair belang (al geef je wel aan dat wachtwoorden dus altijd 'versleuteld' opgeslagen moeten worden vanwege de veiligheid)

Acties:
  • +3 Henk 'm!

  • Stoelpoot
  • Registratie: September 2012
  • Niet online
offtopic:
Overigens zou ik, als sidenote, ook even flink achter m'n oren krabben w.b. m'n toekomst bij zo'n werkgever, als deze niet de technische kennis heeft om te begrijpen dat dit een slecht idee is maar jou er ook niet op vertrouwd dat dit een slecht idee is. Zeker het gebruik van 'onverklaarbaar' is een alarmbelletje in dat opzicht.

Acties:
  • +1 Henk 'm!

Verwijderd

De klant is een idioot. Plain text password overzichten is de grootste anti-security practise die te bedenken valt. Je baas is een idioot om dit idiote verzoek bij jou neer te leggen, maar is waarschijnlijk slechts doorgeefluik.

De "bewijslast" moet omgedraaid worden want dit is de wereld op zijn kop. Jij hebt het juiste gedaan en de klant mag uitleggen waarom hij deze enorm incompetente vraag stelt. Daarna kan de klant zich beter terugtrekken uit het digitale domein.

Wat ook kan is dat de klant super slim is. Dat het een strikvraag is. Als je dit immers zou kunnen aanleveren, dan heb je de basis niet op orde. Maar die kans schat ik klein in.

Nu nog zaak dit politiek correct te verpakken.

Acties:
  • +2 Henk 'm!

Verwijderd

Klanten zijn altijd idioten. Zeker als er wat mis gaat. Hebben overal verstand van ineens en alle registers moeten open!

Social engineering is nu het belangrijkste. Pleister en kusje er op ;)

Iet wat te technisch: standaarden volgens NIST (amerikaans overheidsorgaan dat onder andere standaarden opstelt voor cyber security) https://pages.nist.gov/800-63-3/ (heb ik eens wat systeembeheerders mee om de oren geslagen :D)

Voor zover nog niet in gebruik WordFence of iets vergelijkbaars aanbieden / installeren.

Even Googlen op andere mogelijkheden om verdachte logins te detecteren. En dat voorstellen.

En lief voor ze zijn ;) Er is namelijk iets heel ergs gebeurt (dat de schade herstelt is en, veemoedelijk, weinig impact had, maakt niet uit)

[ Voor 8% gewijzigd door Verwijderd op 22-10-2019 16:42 ]


Acties:
  • +2 Henk 'm!

  • garriej
  • Registratie: December 2012
  • Laatst online: 01-10 11:55

garriej

Ik las ondertieten.

Verwijderd schreef op dinsdag 22 oktober 2019 @ 16:29:
De klant is een idioot. Plain text password overzichten is de grootste anti-security practise die te bedenken valt. Je baas is een idioot om dit idiote verzoek bij jou neer te leggen, maar is waarschijnlijk slechts doorgeefluik.

De "bewijslast" moet omgedraaid worden want dit is de wereld op zijn kop. Jij hebt het juiste gedaan en de klant mag uitleggen waarom hij deze enorm incompetente vraag stelt. Daarna kan de klant zich beter terugtrekken uit het digitale domein.

Wat ook kan is dat de klant super slim is. Dat het een strikvraag is. Als je dit immers zou kunnen aanleveren, dan heb je de basis niet op orde. Maar die kans schat ik klein in.

Nu nog zaak dit politiek correct te verpakken.
Vergeet niet de klant te vragen waarom hij in vredesnaam een simpel wachtwoord gebruikte voor zijn eigen account :+

Acties:
  • +1 Henk 'm!

Verwijderd

garriej schreef op dinsdag 22 oktober 2019 @ 16:42:
[...]

Vergeet niet de klant te vragen waarom hij in vredesnaam een simpel wachtwoord gebruikte voor zijn eigen account :+
Klant direct vertrokken :+

Mijn eerste reactie zou zijn: "waarom heb jij me een systeem geleverd dat dat toe staat!?" })

Acties:
  • +1 Henk 'm!

  • garriej
  • Registratie: December 2012
  • Laatst online: 01-10 11:55

garriej

Ik las ondertieten.

Verwijderd schreef op dinsdag 22 oktober 2019 @ 16:47:
[...]


Klant direct vertrokken :+

Mijn eerste reactie zou zijn: "waarom heb jij me een systeem geleverd dat dat toe staat!?" })
Ja simpel in de cybersecurity is tegenwoordig vrij breed natuurlijk. 8 karakters, speciaal teken en cijfer is vaak de eis als je dan P@ssword1 neemt, dan is dat goed te bruteforcen.

Natuurlijk moet je eigenlijk je backend zo inrichten dat wachtwoorden uit de standaard password dictionaries niet mogen, maar dat wordt bijna niet gedaan in de praktijk.

Sowieso, alleen een wachtwoord is tegewoordig niet meer genoeg.

[ Voor 5% gewijzigd door garriej op 22-10-2019 16:52 ]


Acties:
  • 0 Henk 'm!

  • Critycal
  • Registratie: December 2014
  • Laatst online: 25-10-2019
Bedankt voor alle (snelle) reacties!
Goed om te weten dat ik in ieder geval niet verkeerd gehandeld heb.

Ga er mee aan de slag :)
M.b.t. de reden dat dit uberhaupt gebeurd is; dit was dat het account nog uit een WordPress versie kwam die geen sterke wachtwoorden verplicht (bij het aanmaken/wijzigen van het account), inmiddels wordt er al aangegeven dat bepaalde wachtwoorden onveilig zijn etc. en moet je meerdere checks omzeilen om dit wel voor elkaar te krijgen.

Wat betreft de WordFence tip; deze draait inmiddels op alle sites!

Helaas te veel goeie antwoorden om een concreet "beste antwoord" te kiezen, maar in ieder geval iedereen hartelijk bedankt voor de support ;)

[ Voor 15% gewijzigd door Critycal op 22-10-2019 17:05 . Reden: aanvulling ]


Acties:
  • 0 Henk 'm!

Verwijderd

[@Critycal dat soort shit gebeurt nu eenmaal. En toch gaan mensen die checks voor sterke wachtwoorden willen negeren...

Een mooie oplossing is om bekende wachtwoorddatabases (die zijn online eenvoudig te vinden) te vergelijken met de wachtwoorden van de gebruikers. Ook de bestaande wachtwoorden!

Dat kan ook zonder dat je de wachtwoorden zelf kent omdat deze versleuteld in de database staan. Je kent de manier waarop wachtwoorden versleuteld worden in WordPress. Je neemt de lijst met bekende en makkelijk te raden wachtwoorden, versleutelt deze op dezelfde manier en vergelijkt het resultaat met de versleutelde wachtwoorden in de database. Als die gelijk is weet je dat het een onveilig wachtwoord is zonder het wachtwoord zelf te kennen.

Ik heb gedetacheerd gezeten bij een grote internet provider die security belangrijk vindt - bonuspunten voor wie weet wie ik bedoel ;) - en daar heeft beheer zo’n scan eens uitgevoerd.

Kan niet goed inschatten hoe je technische skills zijn. Zegt md5 je bijvoorbeeld iets of bcrypt? Salts? En kun je dat verkopen aan je baas / klant? Dan piemel ik wel even stukje tekst voor je in elkaar ;)
Pagina: 1