1Password gaat wachtwoorden controleren via Have I Been Pwned

1Password is een van de eerste diensten die gebruik gaat maken van de vernieuwde database van Have I Been Pwned, om ingevoerde wachtwoorden te controleren. Voorlopig gaat het nog wel om een proof of concept.

Voor het controleren van wachtwoorden haakt 1Password in op de Pwned Passwords-database van Have I Been Pwned. Donderdag werd bekend dat beveiligingsonderzoeker Troy Hunt die database heeft uitgebreid en beschikbaar heeft gemaakt voor andere partijen, die deze onder andere via een api kunnen benaderen.

Bij de proof of concept van 1Password kunnen gebruikers van de online wachtwoordbeheerder controleren of een wachtwoord dat ze willen toevoegen, voorkomt in de database van meer dan vijfhonderd miljoen uitgelekte wachtwoorden. Gebruikers kunnen na het inloggen en het openen van een Vault de toetscombinatie Shift-Control-Option-C gebruiken om de proof of concept tevoorschijn te toveren.

"Als je wachtwoord gevonden wordt, betekent dat niet meteen dat je account onveilig is. Iemand anders kan hetzelfde wachtwoord gebruiken", meldt 1Password, dat wel adviseert dan hoe dan ook een wachtwoord te wijzigen. De dienst gaat de koppeling met Pwned Passwords toevoegen aan zijn Watchtower-dienst voor 1Password-abonnees, dat al waarschuwt voor het gebruik van kwetsbare wachtwoorden.

Reacties (102)

Maar als hij dus geen match heeft met de database, is dat wachtwoord toch over het internet gegaan en in principe ook niet meer zo veilig.

Edit, ok er zit dus wel iets van 'veiligheid' in, maar nog steeds vrij gelimiteerd.

First, 1Password hashes your password using SHA-1. But sending that full SHA-1 hash to the server would provide too much information and could allow someone to reconstruct your original password. Instead, Troy’s new service only requires the first five characters of the 40-character hash.

To complete the process, the server sends back a list of leaked password hashes that start with those same five characters. 1Password then compares this list locally to see if it contains the full hash of your password. If there is a match then we know this password is known and should be changed.

[Reactie gewijzigd door SinergyX op 23 februari 2018 16:35]

Als je zo denkt dan kan je niks meer veilig over het internet sturen, zo te zien hebben ze bij 1password de zaakjes wel op orde voor deze service:

Before I dive into the explanation, I want to reiterate that Troy’s new service allows us to check your passwords while keeping them safe and secure. They’re never sent to us or his service.

First, 1Password hashes your password using SHA-1. But sending that full SHA-1 hash to the server would provide too much information and could allow someone to reconstruct your original password. Instead, Troy’s new service only requires the first five characters of the 40-character hash.

To complete the process, the server sends back a list of leaked password hashes that start with those same five characters. 1Password then compares this list locally to see if it contains the full hash of your password. If there is a match then we know this password is known and should be changed.

Goede quote, maar een raar antwoord. Als er iets is waar je heel voorzichtig mee om moet gaan dan zijn het wel wachtwoorden. Dat je vandaag de dag met een kritische blik kijkt naar een dergelijke leverancier lijkt me gewoon gezond verstand. Zomaar aannemen dat het veilig is vind ik wat naïef eigenlijk ...

1Password heeft een goeie track record. Ik gebruik het al sinds versie 1. Ik denk dat het zowat de eerste password manager moet geweest zijn. Vervolgens zie je dan een heleboel password managers opduiken maar zie je ook de eerste problemen opduiken met die password managers. Het valt op dat 1Password nog geen ernstige problemen is tegen gekomen. Ik zeg niet dat het nooit kan gebeuren maar ze denken bij 1Password wel heel goed na over beveiliging.

Je moet iemand kunnen betrouwen met paswoorden, op mezelf kan ik daar echt niet op rekenen en dan heeft 1Password toch wel al bewezen een goede investering te zijn. De opmerking van SinergyX is terecht. Ik had ze niet gesteld maar blijkbaar was er wel over nagedacht.

Je kan wel zeggen dat je niet zomaar mag aannemen dat alles veilig is maar als je zelf niet weet hoe het moet zul je wel blind moeten vertrouwen op mensen met expertise. Het is dus gokken en ik denk dat 1Password voor leken dan de beste gok is.

Als je meer informatie wilt, op het Cloudflare blog staat een tekst waarin uitgebreider uitgelegd wordt hoe dit precies werkt: Validating Leaked Passwords with k-Anonymity

Trust but verify! (Ronald Reagan).

Verify and verify again then trust ( Lord Anubis )

Alleen de eerste 5 tekens van de SHA1 hash worden gestuurd en lokaal worden die matches van de database vergeleken met je wachtwoorden. Je eigen wachtwoorden worden dus niet over het internet verstuurd!

Edit, ok er zit dus wel iets van 'veiligheid' in, maar nog steeds vrij gelimiteerd.

Wat is er nou precies nog "gelimiteerd" aan de veiligheid volgens jou? Je bent van mening dat 5 tekens van een hash van 40 tekens teveel informatie blootgeeft? Dat zijn 20 bits van de 160, dan hou je dus nog 140 bits over. Ruim voldoende en absoluut niet herleidbaar naar de originele hash.

Wat is er nou precies nog "gelimiteerd" aan de veiligheid volgens jou? Je bent van mening dat 5 tekens van een hash van 40 tekens teveel informatie blootgeeft?

Het is hoe dan ook 20 bits aan informatie die naar een third party gaan. En ja, dat kan significant zijn.

Stel, jouw wachtwoord van Tweakers.net bestaat uit 7 willekeurige tekens uit [A-Za-z0-9]. Dat geeft je wachtwoord 62⁷ mogelijkheden (een cryptographic strength van ongeveer 42 bits). En stel, Tweakers.net staat per gebruiker 1 login-poging per seconde toe (zonder verdere maatregelen).

Zonder verdere informatie moet de aanvaller 62⁷ pogingen doen in evenveel seconden; ruim 100 000 jaar.

Maar wat nou als de aanvaller toegang tot die 20-bit hash fingerprint van jouw wachtwoord heeft gekregen? Dan kan de aanvaller voordat hij een poging doet bij Tweakers.net (wat een seconde kost) eerst het kandidaat-wachtwoord zelf SHA1-hashen (makkelijk < 1µs) en controleren of de eerste 20 bits overeenkomen met de afgeluisterde fingerprint. Komt dat niet overeen, dan probeert de aanvaller het niet eens bij Tweakers.net en hasht+controleert hij snel het volgende kandidaat-wachtwoord.

Slechts 1 op de 2²⁰ ≈ 1 miljoen wachtwoorden zal de fingerprint matchen. Met deze informatie hoeft de aanvaller dus een miljoen keer zo weinig wachtwoorden bij Tweakers.net te proberen! Nu kost brute-forcen hem nog maar 62⁷ / 2²⁰ / 86400 ≈ 39 dagen in plaats van meer dan 100 000 jaar. Oeps. Voor on-line aanvallen is je wachtwoord effectief van 42 bits sterkte naar 42 - 20 = 22 bits gegaan.

Dit is natuurlijk een veel kleiner probleem met een echt sterk wachtwoord, maar zwakke wachtwoorden (zwakker dan dit!) komen veel voor. Het illustreert in ieder geval dat een schijnbaar onschuldige "20 bits van SHA-1" misschien toch niet zo onschuldig is...

[Reactie gewijzigd door deadinspace op 23 februari 2018 18:39]

Ik ben gestopt met lezen toen je schreef "Stel, jouw wachtwoord van Tweakers.net bestaat uit 7 willekeurige tekens uit". Dat is niet hoe 1Password werkt. 1Password creëert geen zwakke paswoorden. Dus is het toch helemaal niet relevant.

Als je uitgangspunt de echt sterke wachtwoorden van 1Password is dan hoef je ze ook niet te controleren. Een sterk nieuw wachtwoord (heel random van voldoende lengte) zal namelijk echt niet voorkomen bij 'Have I Been Pwned'

Toch wel. Stel dat een database met paswoorden in plain-text is gekraakt dan is dat sterk paswoord onveilig geworden en moet je het aanpassen

Je gaat er van uit dat een aanvaller weet hoe lang en hoe complex een wachtwoord is. Wanneer je dit niet weet maken die 20 bits ineens veel minder uit.

Je gaat er van uit dat een aanvaller weet hoe lang en hoe complex een wachtwoord is.

Als je een security-analyse doet, dan moet je dergelijke aannames maken; je moet er van uitgaan dat de aanvaller alles weet over je werkwijze behalve daadwerkelijke sleutels of wachtwoorden. Dat staat bekend als Kerckhoffs's principle.

Stel, een aanvaller heeft al een aantal van je wachtwoorden buitgemaakt, en deze zijn allemaal [A-Za-z0-9]{7}. Dan kan de aanvaller ervan uitgaan dat dit wachtwoord daar ook aan voldoet, en kent hij dus de structuur en lengte van je wachtwoord.

Bovendien was het maar een voorbeeld; mijn punt was voornamelijk dat die gedeeltelijke hash het aanvallers makkelijker maakt, en dat dit meer scheelt dan mensen zich misschien realiseerden.

Wanneer je dit niet weet maken die 20 bits ineens veel minder uit.

Het levert de aanvaller nog steeds 20 bits aan informatie op, waarmee hij een on-line aanval een factor miljoen sneller kan uitvoeren. Dat is onafhankelijk van de structuur van het wachtwoord.

Maar nu ga je er vanuit gaat Tweakers 1 wachtwoordpoging per seconde toestaat. Nu weet ik niet hoe Tweakers dit doet maar de meeste sites hebben gewoon een oplopende backoffice of een geforceerde blokkering na een aantal pogingen.

Onbeperkt proberen zou bij een normale site niet mogelijk moeten zijn. Een vergeet niet dat het al heel moeilijk gaat zijn om die hash te pakken te krijgen als het via SSL gaat.

[Reactie gewijzigd door GekkePrutser op 23 februari 2018 19:05]

Onbeperkt proberen zou bij een normale site niet mogelijk moeten zijn.

Zo zou het misschien moeten zijn, maar ik durf te wedden dat onbeperkt proberen bij meer sites wel mogelijk is dan niet. Denk daarbij vooral aan kleinere sites, random fora en webshops en dergelijk...

Een vergeet niet dat het al heel moeilijk gaat zijn om die hash te pakken te krijgen als het via SSL gaat.

Sure. Ervanuit gaande dat je Have I Been Pwned vertrouwt.

Maar dat was mijn punt niet; ik reageerde op de opmerking dat 20 bits van SHA-1 onschuldig zou zijn. Mijn punt was dat dat niet noodzakelijk zo is.

Ik kan fout zitten, maar volgens mij maak je een denkfout.

Ten eerste weet een aanvaller niet hoe lang je wachtwoord is op basis van de hash. Die is immers altijd 160 bytes.
Ten tweede moet hij met de 20 bytes waarover hij beschikt, nog altijd 140 van de 160 bytes achterhalen, en dan heeft hij pas de volledige hash.

Ten eerste weet een aanvaller niet hoe lang je wachtwoord is op basis van de hash. Die is immers altijd 160 bytes.

Dat beweerde ik ook niet

In mijn post deed ik de aanname dat de aanvaller de structuur van het wachtwoord kende. Dat is een verstandige aanname (zie mijn post hierboven). Maar het maakte het vooral makkelijker uit te leggen. Als de aanvaller de structuur van het wachtwoord niet kent dan gaat mijn verhaal nog steeds op, en heeft de aanvaller nog steeds een factor 1 miljoen voordeel.

Een SHA-1 hash is overigens 160 bits, niet bytes.

Ten tweede moet hij met de 20 bytes waarover hij beschikt, nog altijd 140 van de 160 bytes achterhalen, en dan heeft hij pas de volledige hash.

Lees mijn verhaal nog eens

De aanvaller hoeft niet de volledige hash te achterhalen; hij probeert het wachtwoord zelf uit bij Tweakers.net. De truuk is dat die 20 bits hem helpen 999 999 van de 1 000 000 wachtwoorden uit te sluiten, waardoor hij een factor miljoen minder wachtwoorden bij Tweakers hoeft te proberen.

[Reactie gewijzigd door deadinspace op 25 februari 2018 13:50]

Op elke inlogpagina gaat je wachtwoord toch over het internet?

Ik mag hopen van niet

Ik neem aan dat daar een /s achter moet?

Zeker niet. Op elke ook maar enigszins beveiligde website gaat alleen een gehashte variant van het wachtwoord over een encrypted verbinding. Je wachtwoord zelf zou nooit over het internet mogen gaan.

Edit: Ik heb duidelijk te weinig slaap gehad. Zoals in reacties al aangegeven worden wachtwoorden zelden client side gehasht en is beveiling over TLS voldoende om wachtwoorden te beschermen.

[Reactie gewijzigd door BrightSilence op 23 februari 2018 22:12]

Dat is dus niet waar, wachtwoorden worden gewoon 'plaintext' meegestuurd wanneer je ergens inlogt. Daarom is het zo essentieel dat je login pagina op SSL (eigenlijk TLS) draait, zodat de content van je request versleuteld wordt en dus niet gesniffed kan worden.

Er zijn unieke gevallen waar wachtwoorden client side worden gehashed, maar dat is eigenlijk niet meer dan een schijnveiligheid. Het versturen van een hash of het wachwoord zelf staat gelijk aan elkaar, want als een aanvaller een van beide heeft kan hij het request gewoon sturen met de inhoud en zal hetzelfde antwoord krijgen.

Het is niet veel veiliger en onderhevig aan wat haken en ogen, maar je kan zo’n replay aanval wel mitigeren met wat overige technieken erbij. Maar zelfs zonder is het nog altijd nét iets veiliger dan het wachtwoord plain-text versturen, en dan met name vanwege de neiging van mensen om één wachtwoord te gebruiken op meerdere plekken.

Als dan één plek afgeluisterd wordt kan de aanvaller daar wellicht authenticeren, maar niet per definitie bij de overige sites.
Dat is an sich al een winst, al is t marginaal.

Ben t verder wel grotendeels met je eens hoor.

[Reactie gewijzigd door WhatsappHack op 23 februari 2018 17:22]

Punt is natuurlijk ook dat 2FA een veel beter en vooral beproefde methode is om wachtenwoorden te versterken, dan zelf iets bedenken tegen replay aanvallen.

En voor die situaties waar inloggen te frequent is en gebruikers dus gaan klagen, gebruik je een token/key die beperkt houdbaar is die dan verstuurd wordt ipv het wachtwoord zelf, totdat het weer tijd is om met 2FA een nieuwe key/token te maken.

Oh absoluut, het probleem is alleen dat in het dagelijks leven bijna geen hond t activeert en het verplichten veel boosheid en klachten oplevert waardoor men de verplichting veelal opheft.

Eens.

Bij ons is het gelukkig wel verplicht voor vrijwel alles, inclusief webpage interfaces en zelfs het toevoegen van een eigen telefoon op het WiFi netwerk. In combinatie met Microsoft Hello, virtual smartcards en goede token/key policies hoef ik echter slechts 1 keer per dag daadwerkelijk een 2FA uit te voeren. Maar goed, IT hier is dan ook (zeldzaam) goed.

Petje af ja, je ziet niet vaak dat de IT échtbgoed in elkaar zit; laat staan de beveiliging.

Klopt. Dat laatste zou nog (deels) op te lossen zijn door ook iets van een datum, of iets anders wat wisseld erin te verwerken wat 'verloopt' binnen korte tijd.

Je zou random bits op beide plekken kunnen genereren, uitwisselen met elkaar en dan op basis van die informatie een hash in elkaar flansen; maar of t echt veel nut heeft is een tweede. Zeker bij een man in the middle heeft het allemaal maar weinig zin om die extra stappen te ondernemen (immers kan men dan ook de data mogelijk manipuleren ), en SSL is gewoon een oneindig veel veiligere oplossing.

Het helpt hoogstens de plain-text iets te beschermen en script kiddy’s die stoer doen met wireshark maar verder niets kunnen het leven zuur maken; maar voor “the real deal” is t slechts een marginale winst.

[Reactie gewijzigd door WhatsappHack op 23 februari 2018 17:27]

Het is geen schijnveiligheid, omdat normaal gesproken zo'n constructie hash(hash(wachtwoord) + nonce) verstuurd. De database op de server bevat hash(wachtwoord), en de server kan de input dus gewoon valideren. De nonce wordt maar eenmalig door de server geaccepteerd, dus een aanvaller kan de login niet reproduceren.

[Reactie gewijzigd door onionchopper op 23 februari 2018 18:41]

HTTPS is op dat gebied voldoende. Bovendien is het alleen gebruiken van een hash restrictief voor de beveiliging.

1. Als er een zwakte ontdekt wordt in je password algorithm, is het lastig om te wisselen. Als het wachtwoord server-side wordt gehasht, kan het opnieuw worden gehasht met een ander algoritme.
2. Password requirements zijn te omzeilen. Denk aan basale lengte-checks, maar ook controle op vaak gebruikte wachtwoorden.
3. Gebruikers kunnen alleen inloggen als Javascript is ingeschakeld, wat tot op een zeker niveau ook een beveiligingsprobleem is.

Zie ik iets verkeerd? Hij zal versleuteld zijn wanneer er HTTPS gebruikt wordt, maar de hashing gebeurt toch niet client-side?

In een redelijkaantal van de gevallen gebeurt de hasing client-side via bijvoorbeeld Javascript. Zo blijft je wachtwoord binnen de browser en wordt alleen de hash verstuurt

Dat is echter niet veiliger, maar onveiliger.
Normale situatie:
client ---[wachtwoord]---> https ---[ge-encrypt bericht, inclusief wachtwoord]---> server hash(wachtwoord) == hashUitDatabase?

Bij clientside hashing krijg je dan:
client ---[hash]---> https ---[ge-encrypt bericht, inclusief hash]---> server hash == hashUitDatabase?

Het probleem is dat wanneer je toegang tot de database hebt je de hashes kunt zien. Vervolgens kun je deze gebruiken om in te loggen. Met andere woorden: je hebt de hash het wachtwoord gemaakt, dus een databaselek is een wachtwoordenlek.

[Reactie gewijzigd door Marq op 23 februari 2018 17:15]

Dat is echter niet veiliger, maar onveiliger.

Als je de backend gaat aanpassen wel ja, maar dat moet je dan ook niet doen . Een goede backend hasht het wachtwoord met salt. Als de wachtwoorden clientside al gehasht worden, dan hash je aan de backend dus de hash van het wachtwoord met salt. Die laatste stap moet je dan niet ineens achterwege gaan laten.

[Reactie gewijzigd door .oisyn op 23 februari 2018 17:38]

Een goede backend hasht het wachtwoord met salt.

+ past enkele duizenden/tienduizenden rounds van die hash toe. Een enkelvoudige hash - ook met salt - verdient een stevige face-palm

Immers de salt is enkel om te voorkomen dat men pre-gegenereerde databases onbruikbaar zijn om de hashes te kraken. Je moet duizenden rounds hebben om het kraken zelf te vertragen.

> duizenden lijkt me wat overdreven.. en die stevige facepalm valt ook wel mee (imho)

duizenden lijkt me wat overdreven.. en die stevige facepalm valt ook wel mee (imho

Integendeel. Duizenden is vrij normaal. Het klinkt veel, maar met GPU's kun je zo onvoorstelbaar veel hashes per seconde uitrekenen dat minder dan duizenden rounds gewoonweg zwak te noemen is.

Om een voorbeeld te geven, Microsoft bitlocker gebruikt meer dan een miljoen rounds, in combinatie met een iteratieve (waar GPU's een 'hekel' aan hebben) SHA2 gebaseerde hash. Voor websites mag het iets minder, maar daarom schreef ik ook duizenden/tienduizenden. Welke van de twee is afhankelijk van welk hash-gebaseerd algorithme je gebruikt.

Een enkelvoudige hash is dus oprecht een zeer dikke facepalm, want is letterlijk (!) nauwelijks veiliger dan een plain-text opslag. Binnen een paar uur heb je al veel van een dikke database aan wachtwoorden in een enkelvoudige hash met salt omgezet in plain text.

Duizend keer hashen is ook hashen. Als ik zeg "hash met salt" dan impliceert dat niet dat dat een enkelvoudige sha is oid.

Een goede backend gebruikt gewoon bcrypt.

Tenzij je ze op de server ook nog een keer hasht en dat vergelijkt met je database.

Dan ben je toch even ver? Alleen stuur je een hash in plaats van een wachtwoord over. Als iemand dus je verbinding kaapt en je hash steelt is dat het zelfde als dat je nu iemand zijn wachtwoord op die manier steelt. Voor de server is boeit het immers niet of hij een wachtwoord hast of een andere hash want de server krijgt gewoon de tekst die hij moet verwerken.

Je hebt een laag aan de cliënt toegevoegd, maar dat voegt niets toe.

Nee, want de hash in de browser hash je ook nog een keer met een eenmalige seed die je van de server krijgt. De server zelf past deze seed ook toe bij de hash die in de database staat en alleen als die matchen, heb je met de juiste persoon te maken.

Volgens mij werkt dit averechts, als je nu een hash hebt kun je daar niet mee inloggen immers word je invoer gehasht aan de server kant alvorens hij gematched word met de database.

Als jij wat in de database staat eerst nog moet salten alvorens je het vergelijkt met de invoer betekent dat je database record je password is. Immers als je dat hebt en geeft de server jou voor een login poging de one-time salt wat het enige andere is wat nodig is.

Dat kan ook niet anders want de server heeft de informatie niet om de hash die je mee stuurt nog eens te hashen alvorens deze met de database te vergelijken want deze is al gesalt en zal dus niet meer matchen.

De server krijgt een gesalte hash.
De server heeft een hash+ salt.

Normaal krijgt de server het ww, maar de server heeft een gehasht ww. Hij moet dus eerst nog het we wat de client hem geeft hashen in plaats van zijn eigen data.

[Reactie gewijzigd door LOTG op 23 februari 2018 21:11]

Het voordeel is dat als de verbinding gekaapt wordt het wachtwoord niet is in te zien, enkel de hash. Voor de server maakt het niet uit inderdaad.

Ja, maar dan is je hash dus het wachtwoord. Het helpt je alleen als je het wachtwoord op meerdere plekken gebruikt.

Ik denk dat je hier een denkfout maakt. Hashing is geen idempotente operatie. Dit betekent dat je gerust een serverHash(clientsideHash(wachtwoord)) kan doen, waarvan de output niet herleidbaar is tot clientsideHash(wachtwoord) óf wachtwoord.

Wanneer je inlogt, stuurt je browser je wachtwoord naar de server. Normaliter wordt van je wachtwoord aan de serverkant inderdaad een hash gemaakt. Je maakt dus een abstractie van je wachtwoord naar een server-side gegenereerde hash. Deze is niet herleidbaar tot je wachtwoord.

Database pw hash = serverHash(Input)
Waar Input = wachtwoord


Diezelfde abstractie kun je ook tweemaal toepassen. Door je hash nogmaals te hashen, krijg je een tweede hash. Je krijgt door een hash van een hash te nemen, output die wederom niet te herleiden is tot zijn input.

Database pw hash = serverHash(Input)
Waar Input = clientsideHash(wachtwoord)

Of het echt nut heeft? We hebben tegenwoordig steeds meer SSL-verbindingen, dus ik denk het niet.

Het gaat er ook niet om dat je het wachtwoord terug krijgt maar dat het gene wat je naar de server stuurt het mogelijk maakt om in te loggen of die input nu een wachtwoord is of een hash maakt dan niet uit.

Het gaat er om dat in het geval dat je aan de client kant gaat zitten hashen dit eigenlijk gewoon je wachtwoord is. Immers mocht je die hash niet toepassen klopt je login niet.

@CykoByte
Ah duidelijk.

[Reactie gewijzigd door LOTG op 23 februari 2018 20:53]

Ai, nu gaat het bij mij fout. Ik reageerde op Marq's stelling, maar heb perongeluk op jouw comment gereageerd.

Het probleem is dat wanneer je toegang tot de database hebt je de hashes kunt zien. Vervolgens kun je deze gebruiken om in te loggen. Met andere woorden: je hebt de hash het wachtwoord gemaakt, dus een databaselek is een wachtwoordenlek.

[Reactie gewijzigd door CykoByte op 23 februari 2018 20:53]

Het voordeel is dat als de verbinding gekaapt wordt het wachtwoord niet is in te zien, enkel de hash. Voor de server maakt het niet uit inderdaad.

Hiervoor is HTTPS. Ga alsjeblieft niks zelf verzinnen hiervoor. Er is geen voordeel aan DIY security.

Maar als iemand al HTTPS heeft gebroken is het toch nog maar een kleine moeite om de JavaScript te onderscheppen en de hash code eruit te halen.

@henk1994 Daarom gebruik je ook voor elke website een ander wachtwoord...

Ik mag hopen van niet

Zo werkt het echter wel tenzij je zaken als Microsoft Hello gebruikt etc.

Inderdaad maar meestal wel over een SSL verbinding, al zijn er technieken die dit ook vermijden - zoals Secure Remote Password protocol. 1Password heeft hier recent ook een blogpost over geschreven.

Ik mag hopen dat 1Password alleen de hash van jouw wachtwoord opstuurt naar Have I Been Pwned. Daarbij gaat je wachtwoord toch wel over het internet heen als je van 1Password gebruik maakt omdat het om een online wachtwoordbeheerder gaat.

Hoeft niet hoor, met Clipperz wordt alles encrypted naar de client gestuurd en op de pc/browser van de client dus ook pas decrypted met een ingevoerd wachtwoord dat dus nooit verstuurd wordt

Maar ja, op het moment dat je op een website inlogt gaat je wachtwoord wel over het internet heen

Niet als die website op het intranet zit

Nope in principe is 1Password een locale watchwoord beheerder welke online naar devices synchoniseert. Hij haalt dus het wachtwoord uit een locale kluis.
Alleen sinds kort is er een optie via een plug-in om vanuit de online kluis the authenticeren.

Dat kan maar hoeft niet. Ik bebruik 1Password zonder account of cloud sync. Sync tussen desktop en mobiel gaat met een lokale wifi sync.

Ik herinner me volgens mij ook dat Troy Hunt een poosje terug zei dat je een wachtwoord kan checken op zijn site maar als er geen hit was hij je alsnog adviseerde om dat wachtwoord niet te gebruiken mede om deze reden meende ik.

Waarschijnlijk gaat je wachtwoord niet over het internet maar een hash daarvan. Dus je wachtwoord zal zeker nog niet te raden zijn.

Ik persoonlijk ben wel blij met deze functie, zo kan ik toch eens even een rondje maken door al mijn wachtwoorden en daar waar nodig de boel eens updaten.

Vraag me wel af of het zo veel lastiger zou zijn om gewoon de hele database lokaal te cachen. Je kan denken dat dat een groot bestand is, maar platte tekst dus met iet of wat compressie zal er weinig van overblijven en is dat zo binnengehaald lijkt me.

Volgensmij kan je dese downloaden op e site van have I been powned. Volgensmij was deze rond de 6GB

Gecomprimeerd?

7zip file van 8.8GB (https://haveibeenpwned.com/Passwords)

Ah. 😅

Wel bij de les blijven.

nieuws: Troy Hunt breidt verzameling uitgelekte wachtwoorden uit naar half mi...

De database is gewoon offline beschikbaar, is 8,8GB groot en bevat: "Version 2 with 501m hashes and counts of password usage".

.

[Reactie gewijzigd door Sograd op 24 februari 2018 13:05]

Ja, gewoon een leuke honeypot. Niet doen.

Shift control option C?? Geen idee hoe ik dat uitvoer op mijn toetsenbord..

3.Enter the magic keyboard sequence Shift-Control-Option-C (or Shift+Ctrl+Alt+C on Windows) to unlock the proof of concept.

Niet vaak dat MacOS voor Windows wordt gezet

1Password was toen het uit kwam enkel beschikbaar voor macOS (Mac OS X destijds dan technisch gezien). Dus heeft wellicht daarmee te maken

Shift+Ctrl+π ?

1Password is een macOS georiënteerd bedrijf. Zo vreemd is het niet hoor. Veel ontwikkelaars die al populair waren op macOS (OS X destijds) zijn via iOS (App Store) heel snel heel groot geworden. Veel inkomsten betekend dat je personeel kan aannemen om andere platformen zoals Android en Windows te bedienen.

Werk je met macOS dan kom je toch vooral die volgorde dus tegen (Mac-Windows). Andersom doet bij mij meestal alarmbellen rinkelen

Option is Alt toch?

Ja.

"Option" op een Mac toetsenbord is vergelijkbaar met Alt voor PC. Dus waarschijnlijk zal de Windows versie Ctrl+Alt+Shift+C gebruiken

Ik zag dit laatst op Facebook. Een paar mensen waren sceptisch totdat ze een prive bericht kregen. Hun reactie was over het algemeen "ok ik ga het wel aanpassen"

Voor keepass is er ook een plugin: https://github.com/andrew-schofield/keepass2-haveibeenpwned

Omdat passwords checken niet veilig is doet deze plugin dat niet.

Niet veilig? Onzin!

Er wordt slechts een klein begin van de hash verstuurd om een lijst te krijgen met hashes die daarmee beginnen, en dan gaat het systeem dat lokaal verder vergelijken. Wat is er dan zo onveilig aan?

Dat hebben ze nu weer aangepast inderdaad, maar de eerste implementatie was zeker wel onveilig.

Ik vind dit wel een toffe aanvulling!
Mijn password management is zoveel verbeterd sinds ik 1Password gebruik. Er zijn slechts nog een handjevol websites waarvan ik het wachtwoord weet...de rest...geen idee. Goed initiatief om deze extra check in te bouwen.

Ik gebruik 1Password al enkele jaren, hetzij een standalone abonnement dat ik destijds heb aangeschaft. Ben aan het twijfelen om een 1Password.com subscription te nemen, maar ergens vind ik het niets dat alles in de cloud staat. Nu zal het wel goed beveiligd zijn maar toch....Het is via de cloud wel onwijs makkelijk delen met anderen.

Waarom zou je je 1PW data in de cloud moeten zetten als je een abonnement neemt, dat hoeft nu toch ook niet?

Als ik het goed begrijp werkt dit alleen als je een 1Password account online hebt?
Dus niet als je, zoals ik, in 2013 een licentie hebt gekocht voor 1Password dat nog toen nog niet in de App Store verkrijgbaar was?

In het bron-artikel staat:

In future releases we’ll be adding this to Watchtower within the 1Password apps, so you can see your pwned passwords right in the 1Password app you use every day.

Kortom, het komt er wel aan. Het werkt nu alleen in de online versie van 1Password. En die gebruik ik ook niet.

LOL

Dan is het voor de hackers straks makkelijk alleen 1Password hacken en hebben ze weer alle wachtwoorden ^^

Hoe makkelijk kun je het ze maken?

Dat geld toch voor alle password managers? Of denk je dat Chrome/Firefox/etc. zijn optie om wachtwoorden voor je bij te houden zo veel veiliger is.

Nee, alleen als je je gegevens uit handen geeft (in de cloud opslaat)

Alle door browsers opgeslagen wachtwoorden zijn remote of lokaal via apps als chromepass te achterhalen. Iets dat deze piraat doormiddel van ervarend leren ontdekt heeft.
https://www.security.nl/p...en+softwarepiraat+gericht

[Reactie gewijzigd door dezwarteziel op 23 februari 2018 20:45]

Hoe was dat eerst niet zo dan? En waarom denk je dat de clouddienst van 1password die wachtwoorden onversleuteld opslaat?

[Reactie gewijzigd door HooksForFeet op 23 februari 2018 18:01]

Dat is wel erg interessant! Ik zou alleen nog wel graag zien om op een veilige manier en zonder externe partij mijn wachtwoord te verifiëren.

Je kan de volledige database van haveibeenpwned downloaden en lokaal vergelijken ook.

Ik heb vandaag al mijn wachtwoorden veranderd met de wachtwoord generator van Bitwarden.

Ik weet niet of dit nou zoveel toevoegt. Als een aanvaller de kans krijgt ook maar een deel van die half miljard wachtwoorden uit te proberen, hebben we het allang over brute force hacking.

Als brute force hacking mogelijk is, en iemand neemt die moeite, is het sowieso een kwestie van tijd voor je gehackt wordt. Waarom zou een hacker deze half miljard wachtwoorden eerst proberen, hij weet immers niet of je je ww daarmee vergeleken hebt. Dus hij probeert ze sowieso allemaal.

Als brute force niet mogelijk is, maar je na een paar pogingen per IP geblokkeerd wordt, komt een hacker statistisch gezien sowieso niet ver.