Helpdesk zou geen wachtwoorden moeten verstrekken
Billy Barron is een veteraan die al vijftien jaar meegaat in de computer en security industrie. Tevens is hij de co-auteur van "Maximum Security 4/e", een boek over de vele facetten van security. Volgens Barron zou de helpdesk van een organisatie niet de mogelijkheid moeten hebben om wachtwoorden te geven of te veranderen. Crackers kunnen namelijk zich voordoen als gebruiker en de helpdesk overhalen om het wachtwoord te geven. Om dit te voorkomen werkt Barron aan een systeem waarbij de gebruiker een aantal persoonlijke vragen moet beantwoorden voordat het wachtwoord verandert wordt. Meer over Billy Barron en security is in dit interview te lezen.
Reacties (16)
22-04-2003, 15:20 door
Wietse
Volgens Barron zou de helpdesk van een organisatie niet de mogelijkheid moeten hebben om wachtwoorden te geven of te veranderen. Crackers kunnen namelijk zich voordoen als gebruiker en de helpdesk overhalen om het wachtwoord te geven. Om dit te voorkomen werkt Barron aan een systeem waarbij de gebruiker een aantal persoonlijke vragen moet beantwoorden voordat het wachtwoord verandert wordt.
Ehmm ligt aan mij hoor maar, in zoon geval stuur je het nieuwe wachtwoord toch op via een aangetekende brief naar het post adres van de persoon in kwestie. In het ergste geval krijgt iemand dus een nieuw wachtwoord zonder daar om gevraagt te hebben. Tenminste zo deden we het hier op mijn werk.
Dan nog iets een wachtwoord sla je toch nooit ergens in clear text op:eek: ? Of ligt dat aan mij, die hash je toch met (SHA-1/MD-4/MD-5/whatever) en je vergelijkt de inlog hash met de opgeslagen hash. Voordeel niemand kan ooit het password uit je database vissen(ook je helpdesk niet), okeej het nadeel is dan dat jij dat ook niet meer om kan om er een te her verstrekken. Maar ja dan stuur je toch ook gewoon een nieuwe op?
Ik vind het nogal eng om te horen dat helpdesk medewerkers passwords kunnen lezen van mensen. Dan hebben ze het in het bovenstaande stuk over crackers maar, ik zou banger :eek: worden voor mijn helpdesk medewerkers zelf dan voor social enginering.
Mzzl,
Wietse
"Am I to believe in every absurdity? If not, why this one in particular?"
Sigmund Freud (The Future of an Illusion)
Ach deze man heeft zichzelf ook in beeld weten te werken door de security 'hype'; zoals Wietse al aangeeft is natuurlijk iedere organisatie in staat een procedure uit te werken om dit te voorkomen.
Best zielig dat deze man na vijftien jaar op zo'n 'lullige' wijze z'n fortuin probeert te maken; zegt wel iets over onze markt... die m.i. dus een echte marktplaats is geworden waar de luidste verkoper de het meeste gehoor heeft... kennis van zaken is (MS-style) niet gewenst.
Sigmund Freud (The Future of an Illusion)
Ach deze man heeft zichzelf ook in beeld weten te werken door de security 'hype'; zoals Wietse al aangeeft is natuurlijk iedere organisatie in staat een procedure uit te werken om dit te voorkomen.
Best zielig dat deze man na vijftien jaar op zo'n 'lullige' wijze z'n fortuin probeert te maken; zegt wel iets over onze markt... die m.i. dus een echte marktplaats is geworden waar de luidste verkoper de het meeste gehoor heeft... kennis van zaken is (MS-style) niet gewenst.
Om dit te voorkomen werkt Barron aan een systeem waarbij de gebruiker een aantal persoonlijke vragen moet beantwoorden voordat het wachtwoord verandert wordt.
Held! Dit wordt al op tig plaatsen gebruikt op het web. Verzin es wat nieuws ofzo. Bijvoorbeeld dat nummerherkenning wordt gebruikt op de helpdesk, en als dat nummer niet overeen komt met het nummer in de klantendatabase, dan worden er geen wachtwoorden verstrekt.
Verder denk ik dat de security lovers hier toch iets te weinig rekening houden met de kosten van waterdichte security. Tis maar net wat er beveiligd moet worden en of het het waard is om de kosten daar voor te maken. Als je de kosten altijd direct doorberekend aan de klanten, gaan die weer klagen.
"Ik wilde alleen een nieuw wachtwoord en nu kost me dat 10 euro!"
22-04-2003, 20:40 door
[Account Verwijderd]
[Verwijderd]
Dit wordt altijd een eindeloze discussie. Er is gewoon geen enkel gemakkelijk systeem te verzinnen waarmee met absolute zekerheid kan worden gesteld dat altijd aan de juiste persoon een wachtwoord wordt verstrekt.
En het heeft ook zo weinig zin. Zelfs als het altijd met absolute zekerheid gedaan wordt is er nog altijd de gebruiker die het wachtwoord gebruikt en je geen vat op hebt hoe veilig die met het wachtwoord omspringt.
Er zijn vele systemen te verzinnen om het verstrekken redelijk veilig te doen. Zelfs die worden helaas vaak al niet toegepast.
En het heeft ook zo weinig zin. Zelfs als het altijd met absolute zekerheid gedaan wordt is er nog altijd de gebruiker die het wachtwoord gebruikt en je geen vat op hebt hoe veilig die met het wachtwoord omspringt.
Er zijn vele systemen te verzinnen om het verstrekken redelijk veilig te doen. Zelfs die worden helaas vaak al niet toegepast.
23-04-2003, 09:19 door
Savatage
Ach, bij ons op het werk gaat het als volgt:
Klant belt op, wordt gekeken of het nummer klopt, en (indien het een bedrijf is) de juiste contactpersoon. Klopt het nummer, bellen we zowieso terug (je kunt je voordoen als iemand anders) en vragen we naar de contactpersoon.
Krijgen we die aan de lijn, wordt het wachtwoord geweizigd, zo niet, pech voor de klant.
Indien de klant zelf niet aanwezig is, maar bevesitgd wordt door meerdere personen dat het wachtwoord vergeten/kwijt/verloren/whatever is, creëren we zelf een nieuw wachtwoord en faxen we dat naar de klant, geen fax, betekend dus per (aangetekende) brief.
Een uitgebreide procedure, maar wel behoorlijk effectief.
Overigens ken ik wel bedrijven/providers waar wachtwoorden in plain text te lezen zijn/waren door helpdeskers.
Klant belt op, wordt gekeken of het nummer klopt, en (indien het een bedrijf is) de juiste contactpersoon. Klopt het nummer, bellen we zowieso terug (je kunt je voordoen als iemand anders) en vragen we naar de contactpersoon.
Krijgen we die aan de lijn, wordt het wachtwoord geweizigd, zo niet, pech voor de klant.
Indien de klant zelf niet aanwezig is, maar bevesitgd wordt door meerdere personen dat het wachtwoord vergeten/kwijt/verloren/whatever is, creëren we zelf een nieuw wachtwoord en faxen we dat naar de klant, geen fax, betekend dus per (aangetekende) brief.
Een uitgebreide procedure, maar wel behoorlijk effectief.
Overigens ken ik wel bedrijven/providers waar wachtwoorden in plain text te lezen zijn/waren door helpdeskers.
23-04-2003, 10:07 door
SirDice
Originally posted by Wietse
Ehmm ligt aan mij hoor maar, in zoon geval stuur je het nieuwe wachtwoord toch op via een aangetekende brief naar het post adres van de persoon in kwestie. In het ergste geval krijgt iemand dus een nieuw wachtwoord zonder daar om gevraagt te hebben. Tenminste zo deden we het hier op mijn werk.
Ehmm ligt aan mij hoor maar, in zoon geval stuur je het nieuwe wachtwoord toch op via een aangetekende brief naar het post adres van de persoon in kwestie. In het ergste geval krijgt iemand dus een nieuw wachtwoord zonder daar om gevraagt te hebben. Tenminste zo deden we het hier op mijn werk.
(real-life scenario)
Directeur marketing belt op: Ik ben mijn wachtwoord vergeten.
Helpdesk: Ok meneer, we zullen u een nieuwe per post opsturen.
Directeur: Maar ik moet nu bij mijn bestanden want ik moet zo een presentatie geven.
Helpdesk: Dat kan niet meneer, procedures.
Directeur: Screw die procedures. Ik wil nu bij mijn bestanden anders sta je op straat.
Helpdesk: ehhhmmm.
Dan nog iets een wachtwoord sla je toch nooit ergens in clear text op:eek: ? Of ligt dat aan mij, die hash je toch met (SHA-1/MD-4/MD-5/whatever) en je vergelijkt de inlog hash met de opgeslagen hash. Voordeel niemand kan ooit het password uit je database vissen(ook je helpdesk niet)..........
Je kan het password niet zo uit de database vissen, ja. Dit voorkomt echter niet dat iemand die hashes eruit vist en op z'n gemak (off-line) gaat zitten brute-forcen.
Tevens is het niet altijd mogelijk om een hash op te slaan. Denk hierbij aan single-signon waarbij niet alle backend systemen geschikt zijn. Dan heb je meestel het clear-text password nodig.
Ik vind het nogal eng om te horen dat helpdesk medewerkers passwords kunnen lezen van mensen. Dan hebben ze het in het bovenstaande stuk over crackers maar, ik zou banger :eek: worden voor mijn helpdesk medewerkers zelf dan voor social enginering.
Helpdesk medewerkers zijn zowieso een gevaarlijke groep. Zij hebben meestal vergaande rechten en kennen het systeem.
Hier loopt de medewerker bij systeembeheer binnen, vraagt om een nieuw wachtwoord, en krijgt het. De oplossing voor dit soort problemen: minder dan 100 man in een bedrijf, dan kun je met 1 systeembeheerder prima toe en nummerherkenning? loop even binnen, derde etage, naast de koffie automaat.
Originally posted by sirdice
(real-life scenario)
Directeur marketing belt op: Ik ben mijn wachtwoord vergeten.
Helpdesk: Ok meneer, we zullen u een nieuwe per post opsturen.
Directeur: Maar ik moet nu bij mijn bestanden want ik moet zo een presentatie geven.
Helpdesk: Dat kan niet meneer, procedures.
Directeur: Screw die procedures. Ik wil nu bij mijn bestanden anders sta je op straat.
Helpdesk: ehhhmmm.
[/QUOTE
Real life scenario:
Directeur marketing belt op: Ik ben mijn wachtwoord vergeten.
Helpdesk: Ok meneer, we zullen u een nieuwe per post opsturen.
Directeur: Maar ik moet nu bij mijn bestanden want ik moet zo een presentatie geven.
Helpdesk: Dat kan niet meneer, procedures.
Directeur: Screw die procedures. Ik wil nu bij mijn bestanden anders sta je op straat.
Helpdesk: Oh, ik dacht eigenlijk dat jij over marketing ging en niet over ICT. Degene die wel over ICT gaat heeft (dit) doorkiesnummer, bel hem, leg het uit en laat hem maar beslissen of we de procedure omzeilen.
Als je managers met grote bek hun zin moet gaan zitten geven, dan op de verantwoording van iemand anders :)
PS
Als je passwords per POST opstuurt is er ook al iets niet helemaal lekker. Dat is namelijk nogal langzaam. Een SMSje doet ook wonderen.
(real-life scenario)
Directeur marketing belt op: Ik ben mijn wachtwoord vergeten.
Helpdesk: Ok meneer, we zullen u een nieuwe per post opsturen.
Directeur: Maar ik moet nu bij mijn bestanden want ik moet zo een presentatie geven.
Helpdesk: Dat kan niet meneer, procedures.
Directeur: Screw die procedures. Ik wil nu bij mijn bestanden anders sta je op straat.
Helpdesk: ehhhmmm.
[/QUOTE
Real life scenario:
Directeur marketing belt op: Ik ben mijn wachtwoord vergeten.
Helpdesk: Ok meneer, we zullen u een nieuwe per post opsturen.
Directeur: Maar ik moet nu bij mijn bestanden want ik moet zo een presentatie geven.
Helpdesk: Dat kan niet meneer, procedures.
Directeur: Screw die procedures. Ik wil nu bij mijn bestanden anders sta je op straat.
Helpdesk: Oh, ik dacht eigenlijk dat jij over marketing ging en niet over ICT. Degene die wel over ICT gaat heeft (dit) doorkiesnummer, bel hem, leg het uit en laat hem maar beslissen of we de procedure omzeilen.
Als je managers met grote bek hun zin moet gaan zitten geven, dan op de verantwoording van iemand anders :)
PS
Als je passwords per POST opstuurt is er ook al iets niet helemaal lekker. Dat is namelijk nogal langzaam. Een SMSje doet ook wonderen.
23-04-2003, 13:09 door
Wietse
Je kan het password niet zo uit de database vissen, ja. Dit voorkomt echter niet dat iemand die hashes eruit vist en op z'n gemak (off-line) gaat zitten brute-forcen.
Hartstikke waar maar als je zorgt dat de database goed is dichtgespijkerd dan wordt het al een heel stuk lastiger als clear text, en dat terwijl hashen (inderdaad op goede backend systemen) een fluitje van een cent is.
Tevens voor echt kritiekere applicaties zou ik geen user-id password aanraden maar hardware-tokens of iets anders in die richting. Okeej is wel duurder maar ja, das altijd de keuze natuurlijk tussen kosten en veiligheid.
23-04-2003, 13:45 door
SirDice
Originally posted by Wietse
Hartstikke waar maar als je zorgt dat de database goed is dichtgespijkerd dan wordt het al een heel stuk lastiger als clear text, en dat terwijl hashen (inderdaad op goede backend systemen) een fluitje van een cent is.
Hartstikke waar maar als je zorgt dat de database goed is dichtgespijkerd dan wordt het al een heel stuk lastiger als clear text, en dat terwijl hashen (inderdaad op goede backend systemen) een fluitje van een cent is.
Je spreekt jezelf tegen hier. Als die database fatsoenlijk dicht zit kan niemand bij die wachtwoorden. Gehashed of niet. Het feit dat ze clear-text worden opgeslagen wil nog niet betekenen dat ze ook clear-text over het 'lijntje' gaan.
Tevens voor echt kritiekere applicaties zou ik geen user-id password aanraden maar hardware-tokens of iets anders in die richting. Okeej is wel duurder maar ja, das altijd de keuze natuurlijk tussen kosten en veiligheid.
Is duurder, beter en veiliger. Helemaal mee eens. Alleen nu heb je nog wat legacy (bedrijfskritische) systemen die hier niet mee overweg kunnen. Wat dan? Die systemen vervangen? Helaas, da's te duur. Een workaround maken waarbij de passwords ergens clear-text worden opgeslagen is dan vaak goedkoper en simpeler. Je dient er dan, uiteraard, wel voor te zorgen dat niet elke Jan L. erbij kan.
23-04-2003, 13:52 door
SirDice
Originally posted by Unregistered
Real life scenario:
Directeur marketing belt op: Ik ben mijn wachtwoord vergeten.
Helpdesk: Ok meneer, we zullen u een nieuwe per post opsturen.
Directeur: Maar ik moet nu bij mijn bestanden want ik moet zo een presentatie geven.
Helpdesk: Dat kan niet meneer, procedures.
Directeur: Screw die procedures. Ik wil nu bij mijn bestanden anders sta je op straat.
Helpdesk: Oh, ik dacht eigenlijk dat jij over marketing ging en niet over ICT. Degene die wel over ICT gaat heeft (dit) doorkiesnummer, bel hem, leg het uit en laat hem maar beslissen of we de procedure omzeilen.
Directeur belt mijn directeur: Ik moet bij die bestanden want.... geld.... blah... blah...Real life scenario:
Directeur marketing belt op: Ik ben mijn wachtwoord vergeten.
Helpdesk: Ok meneer, we zullen u een nieuwe per post opsturen.
Directeur: Maar ik moet nu bij mijn bestanden want ik moet zo een presentatie geven.
Helpdesk: Dat kan niet meneer, procedures.
Directeur: Screw die procedures. Ik wil nu bij mijn bestanden anders sta je op straat.
Helpdesk: Oh, ik dacht eigenlijk dat jij over marketing ging en niet over ICT. Degene die wel over ICT gaat heeft (dit) doorkiesnummer, bel hem, leg het uit en laat hem maar beslissen of we de procedure omzeilen.
Mijn directeur belt mij: Reset jij even dat wachtwoord.
Als je managers met grote bek hun zin moet gaan zitten geven, dan op de verantwoording van iemand anders :)
Breek me de bek niet open over die stropdassen ;)
23-04-2003, 14:12 door
Wietse
Originally posted by sirdice
Je spreekt jezelf tegen hier. Als die database fatsoenlijk dicht zit kan niemand bij die wachtwoorden. Gehashed of niet. Het feit dat ze clear-text worden opgeslagen wil nog niet betekenen dat ze ook clear-text over het 'lijntje' gaan.
[/QUOTE]
Het maakt het voor de beheerders en operators van zoon systeem moeilijker om er bij te komen. Er zijn altijd mensen die bij de database kunnen om beheer uit te voeren. Om 7 * 24 uur support te leveren kom je hier in sommige situaties gewoon niet omheen.
Als je de passwoorden er in de clear in zet is het erg makkelijke en ook aanlokkelijker om ze te misbruiken dan als ze gehashed zijn.
Het merendeel van de beheerders of operators van zoon systeem weet niet eens hoe je moet hashen of hoe een brute force in zijn werk gaat, terwijl de meeste operators of beheerders wel een select * from any-tabel. kunnen uitvoeren.
Je verhoogt de kennis die nodig is van simpel sql naar sql + hash kennis + programmeren voor een brute force. Ik weet het de kennis ligt voor het oprapen maar, je maakt het in iedergeval minder aanlokkelijk.
Is duurder, beter en veiliger. Helemaal mee eens. Alleen nu heb je nog wat legacy (bedrijfskritische) systemen die hier niet mee overweg kunnen. Wat dan? Die systemen vervangen? Helaas, da's te duur. Een workaround maken waarbij de passwords ergens clear-text worden opgeslagen is dan vaak goedkoper en simpeler. Je dient er dan, uiteraard, wel voor te zorgen dat niet elke Jan L. erbij kan. [/B]
Helemaal mee eens.
Je spreekt jezelf tegen hier. Als die database fatsoenlijk dicht zit kan niemand bij die wachtwoorden. Gehashed of niet. Het feit dat ze clear-text worden opgeslagen wil nog niet betekenen dat ze ook clear-text over het 'lijntje' gaan.
[/QUOTE]
Het maakt het voor de beheerders en operators van zoon systeem moeilijker om er bij te komen. Er zijn altijd mensen die bij de database kunnen om beheer uit te voeren. Om 7 * 24 uur support te leveren kom je hier in sommige situaties gewoon niet omheen.
Als je de passwoorden er in de clear in zet is het erg makkelijke en ook aanlokkelijker om ze te misbruiken dan als ze gehashed zijn.
Het merendeel van de beheerders of operators van zoon systeem weet niet eens hoe je moet hashen of hoe een brute force in zijn werk gaat, terwijl de meeste operators of beheerders wel een select * from any-tabel. kunnen uitvoeren.
Je verhoogt de kennis die nodig is van simpel sql naar sql + hash kennis + programmeren voor een brute force. Ik weet het de kennis ligt voor het oprapen maar, je maakt het in iedergeval minder aanlokkelijk.
Is duurder, beter en veiliger. Helemaal mee eens. Alleen nu heb je nog wat legacy (bedrijfskritische) systemen die hier niet mee overweg kunnen. Wat dan? Die systemen vervangen? Helaas, da's te duur. Een workaround maken waarbij de passwords ergens clear-text worden opgeslagen is dan vaak goedkoper en simpeler. Je dient er dan, uiteraard, wel voor te zorgen dat niet elke Jan L. erbij kan. [/B]
Helemaal mee eens.
23-04-2003, 14:30 door
SirDice
Originally posted by Wietse
Het maakt het voor de beheerders en operators van zoon systeem moeilijker om er bij te komen. Er zijn altijd mensen die bij de database kunnen om beheer uit te voeren. Om 7 * 24 uur support te leveren kom je hier in sommige situaties gewoon niet omheen.
Het maakt het voor de beheerders en operators van zoon systeem moeilijker om er bij te komen. Er zijn altijd mensen die bij de database kunnen om beheer uit te voeren. Om 7 * 24 uur support te leveren kom je hier in sommige situaties gewoon niet omheen.
Daarom zei ik al, Helpdesk medewerkers (en ook beheerders/operators) zijn de gevaarlijkste.
Ongeveer 80% van de aanvallen op je netwerk komen van buitenaf. 20% wordt door eigen werknemers gedaan (bewust of niet). Van deze 20% slaagt 80%. M.a.w. de eigen werknemers zijn de kleinste groep 'aanvallers' maar wel de gevaarlijkste.
Originally posted by override
Ik vind de methode die XS4All gebruikt bij het vergeten van wachtwoorden opzich wel een goeie.
Je belt naar de helpdesk met dat je het wachtwoord bent vergeten. Daarna wordt je verplicht jezelf te legitimeren door je legitimatiebewijs door te faxen.
Volgens mij zit je dan al behoorlijk safe.
Ik vind de methode die XS4All gebruikt bij het vergeten van wachtwoorden opzich wel een goeie.
Je belt naar de helpdesk met dat je het wachtwoord bent vergeten. Daarna wordt je verplicht jezelf te legitimeren door je legitimatiebewijs door te faxen.
Volgens mij zit je dan al behoorlijk safe.
Tenzij iemand net een legitimatiebewijs van je gejat heeft en dat op de fax gooit........
24-04-2003, 14:10 door
Wietse
Inderdaad aan een kopie heb je niet zoveel als je het gezicht van de persoon aan de andere kant van de lijn er niet tegen aan kan houden om te verifieren of het wel de juiste is.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
