Fråga:
Internetleverantören hasar inte lösenordet jag loggar in med online. Ska jag vidta några åtgärder?
fluidj
2019-06-11 18:22:06 UTC
view on stackexchange narkive permalink

Jag ringde just kundsupportnumret för min ISP för första gången och blev förvånad över att bli ombedd fjärde och femte tecknet i mitt lösenord, speciellt det jag brukade logga in på mitt konto på deras webbplats, inte ett särskilt lösenord för användning via telefon. Det faktum att de vet vad fjärde och femte tecknet är visar att de inte hasar lösenordet.

Jag tror att GDPR kräver att de lagrar lösenordet säkert, och om de inte hasar det så Jag är säker på att det inte kan betraktas som säkert, så ska jag rapportera dem till någon?

Det enda som får mig att tro att detta kan vara acceptabelt är att det är vanligt att organisationer ber om vissa tecken i en lösenord via telefon. Jag tror att de normalt ställer in ett annat lösenord specifikt för detta, snarare än att använda webbplatsinloggningen.

relaterat: [Tyska chattplattformen Knuddels.de har fått böter på 20 000 euro för att lagra användarlösenord i klartext] (https://www.theregister.co.uk/2018/11/23/knuddels_fined_for_plain_text_passwords/)
Kanske lagrade de fjärde och femte tecknet i lösenordet när du ställer in det. Det skulle också minska säkerheten för ditt konto, men inte lika mycket som att lagra hela lösenordet i återställningsbar form.
Oavsett vad den juridiska sidan av detta är bör du rapportera dem till http://plaintextoffenders.com/. Även om det är kryptering eller vad Phoog nämnde, är det ganska dåligt och de bör pressas för att byta
Jag tittade bara på webbplatsen plaintextoffenders, och jag tycker inte mycket om det. Jag råder människor att hålla sig borta från det.
Det finns olika tekniska tillvägagångssätt för detta som inte innebär att lösenordet är i klartext eller till och med skyddas av reversibel kryptering, så det är fullt möjligt att deras implementering uppfyller kraven i GDPR.
@Moo: Jag tycker att det är mycket tvivelaktigt med tanke på situationen.
https://security.stackexchange.com/questions/7467/how-secure-is-asking-for-specific-characters-of-passwords-instead-of-the-entire
Du har inget bevis alls att de lagrar lösenordet i en annan form än en hash. När du byter lösenord kan de enkelt skapa två hash: 1) hash för hela lösenordet och 2) hash på bara 4: e och 5: e tecknet och operatörerna kan kontrollera det 4: e och 5: e tecknet med den här andra hash. Visst, denna hash kan lätt tvingas oberoende av belastningsfaktorerna för hashing-funktionen, men ditt antagande att de måste lagra lösenordet i en annan form än en hash är helt enkelt falskt
https://security.stackexchange.com/q/92018/15187
Kommentarer är inte för längre diskussion; den här konversationen har [flyttats till chatt] (https://chat.stackexchange.com/rooms/94880/discussion-on-question-by-fluidj-isp-is-not-hashing-the-password-i-log- in-med-o).
På allvar, om någon ville ha några av dina pwd-skivor, kommer de att få det. Försöker du rant eller vad?
Fyra svar:
David Siegel
2019-06-11 20:10:12 UTC
view on stackexchange narkive permalink

GDPR kräver verkligen att lösenordet lagras "säkert". Den specificerar inte vilken teknik som måste användas för detta ändamål. Att hasa PW är en vanlig metod och bör vara tillräcklig om den genomförs korrekt (stark hashfunktion, användning av salt, etc.). Men andra metoder för att säkra lösenordet kan vara tillräckliga. Att kryptera PW istället för att haska det, så att en behörig person kan dekryptera det tillfälligt kan vara OK. Eller kanske en säkerhetsapp separat kan hämta bara de angivna tecknen i PW genom någon form av kryptering. Eller kanske använder ISP inte rätt säkerhet. När det gäller Knuddles i den länkade nyhetsberättelsen inträffade ett faktiskt brott som ledde till att den dåliga säkerheten rapporterades.

Du kan skicka en rapport till lämplig nationell dataskyddsmyndighet.

Kommentarer är inte för längre diskussion; den här konversationen har [flyttats till chatt] (https://chat.stackexchange.com/rooms/94881/discussion-on-answer-by-david-siegel-isp-is-not-hashing-the-password-i- logga in-wi).
Rui Freitas Serrano
2019-06-11 20:52:42 UTC
view on stackexchange narkive permalink

Tja, du kanske har rätt (förmodligen), men då kan du ha fel ...

Som David Siegel nämnde kan de ha krypterat lösenordet och har auktoriserat support personlig dekryptering upp dem -på support-samtal för autentiseringsändamål ...

Vad du kan göra är att skicka en begäran om åtkomst till registrerad med fokus på ditt lösenord och hur de hanterar det på ett säkert sätt ... förklara helt klart samma tvivel som du har lagt upp och ber dem att förklara för dig HUR säkerställer de säkerheten för dina uppgifter, nämligen lösenordet (på ett sätt som de inte tvingas avslöja några "affärshemligheter") men du är fortfarande bekväm och lugn med feedbacken.

Om svaret är "långt ifrån tillfredsställande", använd deras feedback tillsammans med din första fråga för att sammanställa och lämna in ett strukturerat klagomål till din tillsynsmyndighet så att de kan "granskas".

Va? Om lösenordet krypteras ordentligt bör ingen, inklusive "auktoriserad supportpersonal", kunna dekryptera det. Om de kan, * har det inte krypterats * ...
@only_pro Är det inte denna blandning av hashing och kryptering, oftast när du krypterar saker du förväntar dig att människor med en nyckel dekrypterar det
@only_pro-kryptering är per definition en reversibel process. en säker hash är inte kryptering, just för att den inte är reversibel. En hash är inte det enda sättet att göra ett lösenord "säkert" enligt GDPR, även om det är ett mycket vanligt sätt.
Observera att reversibel kryptering inte betyder att supportpersonen kan se dina lösenord. Det betyder att de kan kontrollera tecken i ditt lösenord; för att deras system måste dekryptera PW men behöver inte exponera det. Det ger en mindre sårbarhet än att visa PW för supportpersonal
Svaret är felaktigt eftersom det inte förstår bästa praxis för lösenord. De bästa metoderna för lösenord är att haska dem, inte kryptera dem symmetriskt. Ett rätt hashat lösenord kan inte återställas till dess klartextform. Jag gav ett Stack Overflow-svar som går i detalj om detta här. https://stackoverflow.com/a/4435888/16587 Om någon kan dekryptera ditt lösenord har det inte hashats och det är en säkerhetsproblem som väntar på att hända.
@GeorgeStocker det faktum att hashing är irreversibel och kryptering är reversibel gör inte detta svar felaktigt. Frågan handlade inte om bästa praxis.
George Stockers "syfte" och "omfattning" gör saker exakta eller felaktiga inte "bara för att" ... det du hänvisar till faller i ett specifikt sammanhang och det är inte "lagen" ... det är en uppsättning bästa praxis under specifika omständigheter ... och, som grillen nämnde, handlade frågan inte om bästa praxis men ett specifikt fallsscenario som det är ...
Barmar
2019-06-13 04:06:16 UTC
view on stackexchange narkive permalink

Det är möjligt att de lagrar en hash av hela lösenordet och dessutom lagrar en hash med bara tecken 4-5. Om de alltid ber om samma två tecken när du ringer in är det mer troligt.

4-5 hash är en liten säkerhetsproblem eftersom det skulle vara mycket lättare att knäcka än fullständiga lösenord, och sedan kan det användas för att minska mängden arbete som behövs för att knäcka motsvarande fullständiga lösenord. Eller om någon spricker i den lilla haschen, kan de ringa kundsupport, övertyga repen att de är du och eventuellt få dem att återställa huvudlösenordet (teknisk support måste i allmänhet kunna göra detta om kunden glömmer sitt lösenord och förlorar också åtkomst till e-postadressen som används för att återställa den).

Ángel
2019-06-12 06:07:05 UTC
view on stackexchange narkive permalink

Med fokus på det faktiska problemet måste din ISP ha ett sätt att autentisera sina kunder (ett "lösenord") när de ringer kundsupport. Detta innebär att ett sådant lösenord måste berättas för supportagenten. Naturligtvis skulle det vara en dålig idé att berätta ditt lösenord, så tydligen bestämde de sig för att ställa in deras system som:

  • Lagra lösenordet oskadd internt
  • Deras agenter kan inte se ditt lösenord¹
  • Deras supportprogramvara har har åtkomst till lösenordet i klartext och be om ett par tecken (olika varje gång) för att auktorisera dig.

På det här sättet kommer den person som betjänar ditt samtal högst känner till de två tecken som du har angett.

Jämfört med att ge ditt fullständiga lösenord till dem är det är säkrare. Kanske de till och med t.ex. lagra i klartext² hälften av lösenordet och hash den andra hälften. Det vore önskvärt att de stödde att ha ett annat lösenord för telefonsupport än deras webbplats (kanske gör de men du skulle behöva ställa in ett sådant "telefonlösenord" separat). , det är inte så orimligt, till skillnad från fallet när du autentiserar direkt till deras hemsida utan några mellersta män. Hur som helst, använd inte något känsligt lösenord. Det är bäst om du använder en lösenordshanterare med ett slumpmässigt lösenord som bara används där.

Det är också en bra idé att följa förslaget från Rui Freitas Serrano och fråga dem om deras autentiseringsprocess och hur de skyddar ditt kontos säkerhet.

¹ Så vi hoppas åtminstone.

² Plaintext och reversibel kryptering är mest likvärdiga här

"Lagra lösenordet okrypterat internt" -Du har * inga * bevis på det. Menar du "Lagra lösenordet oskadd internt"? (Det är en helt annan sak.)
@MartinBonner så mycket prat om krypterade lösenord ovan. Du har naturligtvis rätt. Fast.
Ett system där de ber om olika karaktärer varje gång skulle vara ännu värre än att bara be om samma varje gång eftersom det skulle avslöja mer och mer av lösenordet över tid (vilket gör det mycket mindre säkert) och så småningom avslöja hela saken
@KevinWells Om den alltid frågade samma två tecken, skulle dessa två tecken vara lösenordsekvivalenta och tillgängliga för alla supportoperatörer som hanterade dem en gång. OTOH, att variera tecknen innebär att samma roque-operatör skulle behöva hjälpa samma användare flera gånger samtidigt som man håller reda på de tidigare erhållna tecknen, vilket är robustare (speciellt med tanke på att de kontinuerligt hanterar lösenordstecken utan mening, så de kommer _förmodligen_ minns inte dem).
En annan punkt är längden på själva lösenordet och om det valts av användaren (i vilket fall du kanske kan misstänka lösenordet från några tecken) eller genereras slumpmässigt av ISP. Plus, som nämnts ovan, kan teckenplockningsalgoritmen ha några tecken som aldrig begärs av telefonteknikerna och är därför reserverade för fallet när användaren autentiserar sig själv.
@ Ángel Oavsett hur du implementerar den typen av system försämras lösenordets säkerhet, antingen genom att möjliggöra åtkomst till en oseriös operatör som du säger eller genom att avslöja delar av lösenordet som kan ge ledtrådar till resten av lösenordet. Det förutsätter också användaren att vara ok med att avslöja delar av sitt lösenord, vilket är nästan lika illa som att lära dem att ge bort hela sitt lösenord via telefon. Detta system är dåligt och osäkert och alla som försvarar det har fel. Det finns säkra sätt att bevisa din identitet för ett supportteam och detta är inte en av dem
@KevinWells Jag blev förvånad över att jag försvarade att det de gjorde inte var _dåligt. Ja, sådana lösenord ger lägre säkerhet, men jag ser inte ett _perfekt_ sätt att implementera hela tjänsten. Internetleverantören bör stödja att ha separata lösenord, och kunden kan skydda sig genom att använda slumpmässiga, men det finns lite utrymme mer där. Andra lösningar ser jag en eller annan nackdel. Jag skulle vilja höra det säkra sättet du föreslår att OP ISP ska implementera för att autentisera sina kunder via telefon.
@ Ángel Jag kan tänka på ett antal sätt som skulle vara bättre. De kan till exempel skicka verifieringskoder för engångsbruk till kundens e-post eller telefon (den som bifogas kontot), vilket visar att den som ringer är kontoinnehavaren utan att involvera deras befintliga lösenord
@KevinWells tänkte på det, men notera att detta är ISP. Förmodligen också telefonföretaget. "Snälla berätta för mig koden som vi just skickade till din e-post" är en dålig sak att begära från en kund som hävdar "Jag har inget internet". På samma sätt kanske kunden ringer från en fast telefon (som inte kan ta emot sms) utan fungerande mobiltelefon (kunden kanske inte ens har en mobiltelefon!).


ⓘ
Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 4.0-licensen som det distribueras under.
Loading...