Fråga:
Hur säkert lagrar Chrome ett lösenord?
Tony Ruth
2017-10-01 22:23:43 UTC
view on stackexchange narkive permalink

När jag loggar in på en ny webbplats frågar Chrome mig om det ska lagra inloggningsinformationen. Jag brukade tro att detta var ganska säkert. Om någon hittade min dator olåst kunde de komma förbi inloggningsskärmen för någon webbplats med de lagrade uppgifterna, men om de ombeds om lösenordet igen som vid kassan, eller om de ville logga in på tjänsten från en annan enhet, skulle de vara ute av tur.

Det var åtminstone vad jag tänkte när jag trodde att webbläsaren inte lagrade lösenordet i sig, utan en hash eller kryptering av lösenordet. Jag har lagt märke till att webbläsaren fyller i användarnamn och lösenordsfält, och lösenordsfältet anger antalet tecken i lösenordet.

Jag är en av de personer som när de ombeds ändra sitt lösenord bara håller samma lösenord, men ändrar ett nummer i slutet. Jag vet att detta är dåligt, men med hur ofta jag blir ombedd att byta lösenord kunde jag verkligen inte komma ihåg antalet lösenord som jag förväntade mig. Detta resulterar i många lösenord som är desamma, men ibland glömmer jag vad slutnumret måste vara för en viss inloggning.

Jag kunde inte komma ihåg slutnumret för en viss inloggning, så jag gick till en webbplats där lösenordet lagrades. Jag raderade de sista par karaktärerna och försökte olika siffror och viola, visste vad som var rätt slutnummer.

Det verkar för mig att detta är en grundläggande säkerhetsfel. Om jag kan kontrollera det sista tecknet i mitt lösenord utan att kontrollera några andra, kommer antalet försök som krävs för att knäcka lösenordet växer linjärt med antalet tecken inte exponentiellt. Det verkar som ett kort steg därifrån för att säga att om någon kom till min dator när den var upplåst, kunde ett enkelt skript extrahera alla lagrade lösenord för alla större webbplatser som jag har lösenord lagrade för.

Är det inte så? Finns det något annat lager av säkerhet som skulle förhindra detta?

Jag tror att du skulle ha mycket nytta av att använda en lösenordshanterare som LastPass.
Svaret på denna fråga beror i hög grad på vilken webbläsare du pratar om när du säger "en webbläsare".I det här fallet är det Chrome, men i teorin finns det ingen anledning att en annan webbläsare inte kunde hantera lösenord på ett mycket säkrare sätt.Eller kanske en framtida Chrome-uppdatering kan innehålla funktioner som avsevärt förbättrar säkerheten för den här funktionen.Bara något att tänka på när du läser följande svar.
@Awn: Är inte webbläsartillägg ännu värre säkerhetshot?Chrome ger tilläggsförfattaren en obegränsad möjlighet att "uppdatera" den.Detta gör att han kan ladda upp skadlig kod för att stjäla användarnas konto- och lösenordsdata och sedan ladda upp godartad kod igen - och ingen skulle veta det.
För dem som undrar hur _Firefox_ lagrar lösenord har jag ett svar som beskriver det här: https://security.stackexchange.com/a/120666/91904
Chrome måste lagra hela lösenordet (inte hashat) så att det kan skicka lösenordet till webbplatsen.Det finns ingen väg kring detta.
Bästa praxis när du står upp från datorn låser den (för Windows OS låser tangenttryckningen "Windows Key + L" omedelbart), i slutet av dagen är det samma som om du har skrivit dina lösenord men lämnar frontendörren till ditt hus öppen & olåst, du har större problem (och förmodligen förlorat alla dina dyra föremål :)).
AiliaaxmymCMT - https://www.engadget.com/2017/03/22/critical-exploits-found-in-lastpass-on-chrome-firefox/
@Awn Ja, jag går inte tillbaka till LastPass eftersom sårbarheter fortsätter att dyka upp, men jag ** verkligen ** kommer inte tillbaka till [dumma tricks] (https://lifehacker.com/5937303/din-clever-lösenord-tricks-arent-skyddar-dig-från-i dag-hackare) som den som OP nämnde.BTW, OP, du ** behöver ** för att maskin- (eller tärna) generera dina lösenord, handplockning är den värsta fienden till säkerheten.
@NH."Sårbarheter dyker upp."Åh barn."Går aldrig tillbaka till X, eftersom sårbarheter dyker upp.", Där X = Android, iOS, Chrome, Linux, Apache, *
Chrome-lösenordshanteraren är definitivt inte säker.Igår fick jag infektion med skadlig kod (av mitt fel) och allt mitt kromsparade lösenord dumpades i katalogen med skadlig kod i appdata som txt-fil.
Välkommen, @midlan - det verkar som om det borde vara en kommentar snarare än ett svar.Som det står just nu ger ditt svar inget sammanhang eller bevis, förutom din personliga erfarenhet.Antingen posta detta som en kommentar (när du får tillräckligt med rykte för att göra det) eller utvidga ditt svar till att inkludera * hur * lösenordsförvaringen kan äventyras (ja, det kan det, men hur exakt? Under vilka omständigheter?), Tack.
Skadlig programvara kan dumpa alla lösenordslagringar om den låstes upp vid den tidpunkten och Chromes lösenordslagring låses upp när du loggar in.Det gör det inte osäkert, det betyder bara att skadlig kod inte är ett hot som den var utformad för att skydda mot (tillsammans med alla andra lösenordsvalv, om du låser upp dina lösenord medan du har skadlig kod finns det inte riktigt mycket som kan göras).
Nio svar:
Meir Maor
2017-10-02 00:10:12 UTC
view on stackexchange narkive permalink

Chrome lagrar inte bara din lösenordstext, den visar den för dig. Under inställningar -> avancerat -> hantera lösenord kan du hitta alla dina lösenord för alla dina webbplatser. Klicka på Visa på någon av dem så visas den i rensningen.

Hashade lösenord fungerar för webbplatsen som autentiserar dig. De är inte ett alternativ för lösenordshanterare. Många kommer att kryptera data lokalt, men nyckeln lagras också lokalt om du inte har en huvudlösenordsinställning.

Personligen använder jag chrome-lösenordshanteraren och jag tycker det är bekvämt. Jag har emellertid också fullständig diskkryptering och låser min skärm flitigt. Vilket gör risken rimlig imho.

Du verkar vara inkonsekvent (många är) genom att både välja minnesvärda lösenord och använda en lösenordshanterare. Och jag kan våga gissa att du till och med kan upprepa lösenordet eller åtminstone temat på många webbplatser. Detta ger dig det värsta av båda världarna. Du får riskerna med lösenordshanterare utan fördelarna.

Med en lösenordshanterare du litar på kan du ge varje webbplats ett unikt slumpmässigt lösenord som inte är minnesvärd alls och få mycket skydd från många mycket verkliga attackvektorer . I utbyte mot en enda felpunkt för din lösenordshanterare. Även med en mindre perfekt lösenordshanterare är detta inte en orimlig avvägning. Med en bra lösenordshanterare blir detta den bästa praxis för konsensus.

Redigera för att lägga till: läs Henno Brandsma svar som förklarar hur inloggningslösenord och OS-support kan användas för att kryptera lösenord, detta ger en rimlig skyddsnivå för dina lösenord när datorn är avstängd / låst (fullständig diskkryptering är bättre) och det hjälper inte mycket om du lämnar din dator olåst. Även om webbläsaren kräver lösenord för att visa felsökningsverktyg i ren text kan du fortfarande se redan fyllda lösenord som @Darren_H kommentarer. Den tidigare rekommendationen är fortfarande använd slumpmässiga unika lösenord och en lösenordshanterare.

I den senaste Chrome-versionen (68) finns menyn inte i avsnittet Avancerat, utan i det första avsnittet (inställningar -> Människor -> lösenord) - eller skriv helt enkelt "chrome: // settings / passwords" i webbläsarens adressfält
Henno Brandsma
2017-10-02 03:12:17 UTC
view on stackexchange narkive permalink

Chrome (under Windows) krypterar faktiskt lösenorden när de lagras. Men det gör det på ett sätt som bara någon som känner till ditt inloggningslösenord (eller kapar din inloggningssession) faktiskt kan använda eller visa de sparade lösenorden. Detta är väldokumenterat (det använder det så kallade Data Protection API (DPAPI), som finns i Windows från och med NT 5.0 (dvs. Windows 2000) och som idag använder AES-256 för att kryptera lösenordsdata). Google anser att detta är tillräckligt med säkerhet, eftersom det har samma skyddsnivå som hela din inloggning. På Mac eller Linux använder de den inbyggda nyckelringstekniken för att skydda ett speciellt Chrome-huvudlösenord, vilket i huvudsak uppnår samma effekt. Läs källorna för alla detaljer ...

Edge och IE (finns naturligtvis endast i Windows) använder också denna teknik, BTW, under ett omslag som heter Credential Store, i de senaste versionerna av Windows (och innan de använde DPAPI-data lagrade i registret). För mer information om DPAPI, se här, t.ex.

Se https://github.com/byt3bl33d3r/chrome-decrypter för ett exempel på hur människor extraherar lagrade lösenordsdata, med vetskap om dina inloggningsuppgifter.

Nyligen i Windows ändrades systemet till ett system som liknar MacOS: en 256 bitars huvudnyckel lagras (i en separat fil som heter Local State i appkatalogen, base64 kodad och representerad i JSON) som en DPAPI-hemlighet igen och varje lösenordspost är då en hexkodad, AES-GCM-krypterad post i sqlite-databasen i samma katalog (allt under den huvudnyckeln , men var och en med sin egen 12 byte nonce och en 16 byte-tagg för att skydda integriteten). Så det beror så småningom på användarnamnets lösenord. När användarlösenordet (eller snarare dess SHA1-hash) är känt, kan alla poster dekrypteras. Som sagt är detta av design. Till och med Microsofts Edge (Chromium-utgåva) använder detta system nu, som påstås i detta blogginlägg.

På vanliga Linux-stationära system använder Chrome sessionens nyckelring (dvs. GNOME-nyckelring eller KWallet som täcker de allra flesta Linux-skrivbordsinstallationer) som krypterar lösenord med en nyckel som härrör från användarkontolösenordet för lagring.
@DavidFoerster sätter det verkligen ett slumpmässigt "lösenord" för Chrome där som härrör nyckeln som används i lösenordsdatabasen.Nyckelring / plånbok har samma skyddsnivå som inloggningen, precis som Windows har.
Även om det inte är valt som svar, bör detta svar inte förbises och seriöst övervägas av en som försöker bedöma risken med att använda Chrome: s lösenordsbutik och hur man minimerar risken.
Observera på Linux, platsen Chrome lagrar lösenord (vilken nyckelring som ska användas, eller utanför nyckelringen, okrypterad i Chromes datamapp) kan ändras med [--password-store-inställningen] (https://peter.sh/experiments/ chromium-command-line-switches / # password-store).
@Uniphonic LastPass kan se dem eftersom de körs som du, och krypteringsnycklarna är tillgängliga för dig, eftersom Chrome inte har något "salt" som det använder unikt för sig själv, vilket det kan göra.Men att vara öppen källkod innebär att vem som helst kan se det "kromsaltet" också, så att det försämrar syftet.Det andra problemet kommer från Chrome-synkronisering av lösenord över datorer när du loggar in med ditt Google-konto.Det är en inställning som du kan inaktivera om du inte vill att det ska hända.Skadlig programvara som körs på din användarnivå kan verkligen också se den om den är medveten om det.
@HennoBrandsma OK, tack!Jag antar att det också förklarar varför Chrome är sårbart för lösenordsdumpning, som anges i ett annat svar https://security.stackexchange.com/a/170535/165747
Du vet att allt du behöver göra är att kopiera Chrome-användardatamappen till en annan användare.Använd sedan det nya användarkontots lösenord och lås upp lösenordet inifrån Chrome ... Chrome dekrypterar det även om det inte är samma Windows-konto, förutsatt att lösenordet är korrekt.
@NotoriousPyro Nej, det fungerar inte, det andra kontot måste ha samma S-ID och huvudnyckelfiler som det inte har.Det är inte * bara * användarens inloggningslösenord, men du måste klona mycket mer och att ha samma S-ID är förbjudet mellan användare av samma domän etc. så mycket svårt att inse.Att använda DPAPI-dekrypteringsverktyg offline är mycket enklare än vad du föreslår.
Nej du har fel.Jag har gjort det många gånger och kopierat användardata från många olika system och var tvungen att ange mitt nuvarande användarlösenord ... Du borde prova det
@HennoBrandsma Syftet med salt är att förhindra förberäknad regnbågssprickning, så saltet är i allmänhet offentligt, men bör ändras per lösenord.
@HennoBrandsma Tyvärr kollade jag och Chrome tar inte det grundläggande steget att spara ett annat salt per lösenord, så saltet är lite värdefullt, men jag tror att Chromes lösenordsförvaring annars är rimligt säkert.
@NetMage I Linux krypterar de alla lösenord med samma huvudlösenord (förvaras i en nyckelkedja som ett system);inget salt där, medan Windows DPAPI-klumpar har olika salter "inbyggda" av konstruktionen.Windows-systemet är verkligen OK, verkligen.Linux-huvudlösenordet genereras till 128 bitars entropi, så inte brute-forcable.Det läcker ut vilka konton som har * samma lösenord *, Windows-systemet visar inte det.
Elias
2017-10-02 03:00:07 UTC
view on stackexchange narkive permalink

Snälla, snälla, sluta återanvända dina lösenord!

I Firefox kan du faktiskt ställa in ett huvudlösenord som skyddar dina sparade lösenord från att visas. Detta huvudlösenord kommer också att krävas en gång per session innan webbläsaren börjar fylla i lösenord åt dig.

Du kan också använda en lösenordshanterare för allmänt ändamål till exempel Keepass.

Hur som helst, för de flesta människor är risken att förlora ett lösenord eftersom en webbplats har hackats större än att förlora det på sin egen dator. Det beror på att en angripare med åtkomst till din dator har många andra alternativ för att attackera dig. En av de viktigaste fördelarna med att använda en lösenordshanterare är att du inte behöver ange lösenordet manuellt längre så att du faktiskt kan välja helt slumpmässiga och säkra lösenord.

Om du har återanvänt lösenord ett tag det finns en snygg webbplats för att kontrollera några av de mer framträdande överträdelserna för att se om du har påverkats: https://haveibeenpwned.com/

Om du måste använda många olika maskiner du kan överväga att använda något som Keepass2Android på din telefon.

@jiggunjer - så om någon får tillgång till lösenord A, har de tillgång till din bank & google & värd & kryptovaluta & operativsystem.Katastrof. I det minsta bör alla dessa ha tvåfaktorautentisering ELLER ett unikt lösenord.Helst båda.
@Katinka-Hesselink inte min bank eller Google, och mitt operativsystem / plånbok kräver fysisk åtkomst.Det är två faktorer.Ja, de kan få både min webbhotell och min VPN, om de vet vilka tjänster jag använder och vilka e-postmeddelanden som är länkade till dem.Osannolik.
@jiggunjer Jag har lärt mig nu att det som är osannolikt för användaren bara är ett incitament för hackaren.Hackare gillar utmaningar och om de ser en kommer de att gå för det.
Teun
2017-10-02 20:04:21 UTC
view on stackexchange narkive permalink

Du kan också visa lösenord i Chrome genom att ändra HTML. Ändra typen av inmatningsfält till "text" så kan du se förfylld information i klartext. Om någon på din dator känner till en webbplats som du är registrerad på och Chrome fyller ditt lösenord automatiskt kan de se det.

Daniel Grover
2017-10-03 00:21:44 UTC
view on stackexchange narkive permalink

Chrome är sårbart för lösenordsdumpning. Det finns många verktyg där ute som dumpar Chrome-lösenord. LaZagne är en av dem. Du behöver inte ens administratörsbehörigheter eller referenser eller något annat.

Detta är tydligen så enkelt som att ansluta till SQLite-databasen och sedan ringa Win32CryptUnprotectData för att dekryptera lösenordet.

https://github.com/AlessandroZ/LaZagne

En skadlig användare kan helt enkelt köra det här lösenordet eller installera skadlig kod och sedan fjärrköra det här verktyget . En icke-teknisk användare skulle emellertid inte kunna utföra denna uppgift. Därför är det säkert att lagra lösenord i webbläsaren mot icke-tekniska personer, men ineffektivt mot skadlig programvara eller tekniska användare.

Om krom använder AES-256-kryptering, hur knakar LaZagne databasen?
Om man tittar på källan (https://github.com/AlessandroZ/LaZagne/blob/master/Windows/lazagne/softwares/browsers/chrome.py#L82) verkar det som om det går som du har det tillgång till dinskyddade data.Detta är egentligen inte en attack som kan användas för att komma åt andra användares data.
Frågan handlar om att någon kommer åt sin dator när han är obevakad.Dessutom, med administratörsbehörigheter som erhållits genom UAC-förbikoppling eller andra sårbarheter som dll-kapning, kan alla användares data nås.
@jiggunjer Se mitt svar ovan, det använder DPAPI vars säkerhet i slutändan beror på din inloggningslösenordsstyrka (om angriparen inte kan dumpa processminnet, där nycklarna också finns).Om du kör det själv gör Windows dekryptering med CryptUnprotectData eftersom du har tillgång till dina egna nycklar.
Christophe Roussy
2017-10-02 17:08:25 UTC
view on stackexchange narkive permalink

Den största faran är att ha en webbläsare utan huvudlösenord och lämna din dator utan att låsa det: Vem som helst kan sedan snabbt ta en bild av dina sparade lösenord, det tar bara några sekunder. Så det är uppenbart: Lås alltid din dator och ställa in ett huvudlösenord, använd inte lösenord eller liknande mönster igen ...

För att få Chrome att visa ett lösenord i ren text måste du ange ditt inloggningslösenord.Och det kommer bara att göra en i taget.Såvitt jag kan säga finns det inget sätt att få det att visa alla dina lösenord.
Så det är säkrare än Firefox-standard.
Låter som en tidsbaserad automatisk utloggningstillägg kan vara en bra idé.T.ex.logga ut krom efter 15 minuters inaktivitet.
allo
2017-10-05 19:39:38 UTC
view on stackexchange narkive permalink

Det beror på din plattform.

På Linux använder Chrome kwallet / gnome-nyckelring på KDE eller gnome-skrivbordet, vilket båda borde ge bra säkerhet. På OSX använder den OSX-nyckelringen, som också har god säkerhet. På Windows implementerar de sitt eget lösenordslagring, vilket inte är lika säkert som systemnycklarna på det andra operativsystemet.

För de specifika svagheterna i Windows-implementeringen se de andra svaren.

Tgr
2017-10-02 12:36:30 UTC
view on stackexchange narkive permalink

Om du är orolig för att någon kommer åt din bärbara dator medan du är inloggad (t.ex. använder du den på jobbet eller på en offentlig plats och ibland lämnar den oskyddad, eller om du inte litar på en familjemedlem), lagrar du lösenordet i en webbläsare är inte en bra lösning. Om du är orolig för skadlig programvara på din dator (som kan fånga din typ) eller om folk ser vad du skriver, är det ganska säkert mot det, och det är mycket vanligare problem.

Detta svar är omvänd imo.Det är osannolikt att icke-tekniska smarta användare kan få lösenord i klartext, men skadlig kod kan enkelt dumpa dem utan användarinteraktion.Se mitt svar.Du kan köra verktyget själv om du inte tror på mig.
Chrome med ett huvudlösenord är lika bra skyddat mot lösenordsstöld som en lösenordshanterare.(Det vill säga inte särskilt bra. Om något körs på din maskin och har samma åtkomsträttigheter som du har, är dina chanser att förhindra att den stjäl dina lösenord ganska begränsade.) Utan ett huvudlösenord är varken webbläsare eller lösenordshanterarekan ge mycket försvar.
John Denniston
2017-10-04 18:01:29 UTC
view on stackexchange narkive permalink

Det är ganska säkert att ingen mekanism är 100% säker, men vissa mekanismer är säkrare än andra. På den enklaste nivån är ett långt lösenord säkrare än ett kort lösenord men är svårare att komma ihåg och skriva korrekt. Vad du måste bestämma är var balansen mellan säkerhet och användarvänlighet ligger. Lösenordshanterare är ett svar om kostnad / risk-förhållandet känns rätt för dig.

Om du inte litar på någon mekanism som lagrar ditt lösenord på din dator är ett sätt att komma runt detta att använda en algoritm att skapa en åt dig varje gång du behöver den. Jag råkar använda ett litet program som implementerar en variant av Playfair ( https://en.wikipedia.org/wiki/Playfair_cipher) för att generera en del av mitt lösenord för en viss webbplats - vilket har fördelen att jag kan skapa det för hand om jag måste. Undvik dock triviala algoritmer (som att bara vända bokstäverna på en webbplats).

Många företag kräver att du byter lösenord regelbundet. Detta brukade vara standard, men GCHQ avråder nu från praxis (se https://www.ncsc.gov.uk/articles/problems-forcing-regular-password-expiry), för mycket anledning till att du nämner. Förhoppningsvis kommer detta krav att bli mindre vanligt med tiden.



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 3.0-licensen som det distribueras under.
Loading...