Why am i not surprised?

Wat bedoel je?
Dat het gecontroleerd wordt wie wat doet (sleepnet) en vervolgens de overtreders aangepakt worden (ontslagen wegens kngeschiktheid). Dat lijkt me terecht.

"Ook kijkt Ring of wachtwoorden van gebruikers niet via datalekken bij andere websites of diensten openbaar zijn geworden"

Dus Ring heeft je plain tekst wachtwoord en gebruikt dat zonder jouw toestemming, mooi spul man.

Waarom moeten medewerkers van Ring die beelden bekijken? Die beelden zouden alleen voor de klant toegankelijk moeten zijn en voorzien zijn van een versleuteling.*


* Ik zie op de site geen enkel product wat meekijken noodzakelijk maakt.
https://nl-nl.ring.com/pages/protect-plans

Karma4, Ik noem het logging en auditing wanneer je toegang tot persoonsgegevens controleert op rechtmatigheid. Met een sleepnet worden grote hoeveelheden rechtmatige data verzameld in de hoop dat er in de bijvangst bewijs voor crimineel gedrag aanwezig is.

4 die GEVONDEN zijn door de logging/auditing uit te voeren.

Goed werk maar mijn onderbuik gevoel zegt mij dat er meer zijn die ongeauthoriseerd de beelden hebben bekeken maar dat zij door de mazen geglipt zijn.

Is het Nederlands in de ban hier?

En als je dan zo hopeloos onnodig Engels wilt gebruiken doe het dan foutloos anders is het totaal een exposé van domheid.
am I i.p.v. am i

Gezien de gehaastheid waarmee Karma zijn berichten typt denk ik dat hij er niet goed over nagedacht heeft.
Ik ben het volkomen met jou eens dat het niks met een sleepnet van doen heeft waar Karma4 overigens wel een fel voorstander van is.

Er zijn websites waar je gevonden hashes kan vergelijken. Als hashes niet gesalt zijn dan kan je daar simpel op zoeken.
Kan me voorstellen dat Ring bijvoorbeeld kijkt of de hash van je wachtwoord geleaked is.

Een hash die niet gesalt is is in deze tijd bijna net zo bagger als plain tekst, volgens mij zou het dan ook inhouden dat Ring a) of plain tekst b) unsalted hashes bewaard. Immers het zout wordt toegevoegd tijdens het maken van de hash en zou Ring deze nooit moeten kunnen vergelijken.

Maar het is niet helemaal mijn 'vakgebied' moet ik toegeven.

Erik van Straaten?

Indien jouw password *via een andere dienst of website* openbaar wordt, dan heeft dat geen betrekking op de vraag hoe bij Ring de wachtwoorden zijn beveiligd.

Doet me denken aan de mensen die tegen KPN gingen klagen, nadat via Babydump hun wachtwoorden op straat kwamen te liggen.

Verder ben je zelf degene die beslist, of je wachtwoorden hergebruikt, bij verschillende diensten.

Hoe de dienst technisch in elkaar zit doet er niet zoveel toe het gaat erom hoe de medewerkers van zo'n bedrijf ermee omgaan. Als leverancier van diensten kun je vaak bij gevoelige data, dat wil niet zeggen dat je dat dan ook moet doen als daar geen gegronde reden voor is.

Dat derden bij de data kunnen is gewoon slecht, blijkt maar weer dat een hipster bedrijf is gestart met een idee om zsm financieel uit te melken. Er is geen manier om de deurbellen te updaten op een eenvoudige, lees voor gebruikers uit te voeren, manier. Dit zou een van de vereisten moeten zijn om een dergelijk apparaat te leveren/kopen.

Er zijn ook lijsten met (veelgebruikte) wachtwoorden. Je ziet tegenwoordig steeds vaker dat organisaties die controleren als iemand een nieuw wachtwoord opgeeft. Dus voordat het gehasht wordt opgeslagen.

Toen ik de opmerking las, dacht ik gelijk aan deze werkwijze.

Peter

Dat hoeft niet. Want de werkelijke - lost in translation - gedachte zal waarschijnlijk zijn geweest dat men controleert of het e-mail adres van gebruikers niet bij datalekken op andere sites voorkomt. Vanuit de rationale dat men vaak hetzelfde wachtwoord gebruikt op verschillende sites.

Het toevoegen van een salt aan een zwak wachtwoord om het "sterker" te maken is een paardenmiddel, omdat de salt onversleuteld bij de hash wordt opgeslagen.

Als er voor die specifieke salt nog geen rainbow table bestaat van de meest gebruikte wachtwoorden, bestaat de "hindernis" die de aanvaller moet nemen uit het zelf genereren van die specifieke rainbow table. Aangezien dat voor bijvoorbeeld de 1000 meest voorkomende wachtwoorden zo gepiept is, heeft een salt nauwelijks zin als jij een van die 1000 wachtwoorden gebruikt.

State-of-the-art is niet hashen, want de meeste hash-algoritmes zijn ontworpen om zo snel mogelijk door zelfs kleine CPU's te worden uitgevoerd. Een beetje grafische kaart berekent miljoenen SHA hashes per seconde (https://www.techradar.com/news/best-mining-gpu).

Veel beter zijn algoritmes die traag zijn en daarbij veel geheugen en CPU-performance vereisen, zoals bijv. Argon2 kan (afhankelijk van de meegegeven parameters). Een probleem bij zwakke hardware (zoals een deurbelcamera) is dat je natuurlijk niet 10 minuten wilt wachten na het invoeren van je wachtwoord tot je toegang krijgt. Als een aanvaller over extreem veel snellere hardware beschikt, kan hij nog steeds in relatief weinig tijd de meest bekende wachtwoorden proberen.

ECHTERRRR.... het bovenstaande is alleen van toepassing als de aanvaller de wachtwoordhashes heeft weten te bemachtigen, en dat zou betekenen dat hij al ingelogd moet zijn geweest: ofwel gebruik makend van een geldig wachtwoord (mogelijk verkregen via een gehackte ring server, foute medewerker of malware op jouw smartphone), ofwel via een exploit. In geen van die gevallen zal zo'n aanvaller nog geïnteresseerd zijn in wachtwoordhashes...

Als dat met een geldig wachtwoord is gebeurd, moet dat haast wel het factory default password zijn, of moet het geldige wachtwoord op andere wijze zijn verkregen, of moet een van de allermeest gebruikte wachtwoorden (zoals 123456, secret, letmein, admin, qwerty, whiskey) zijn ingesteld, OFWEL moet zo'n ring device niet over fatsoenlijke (tijdelijke) account-lockout functionaliteit beschikken.

Immers, de reden dat een 4-cijferige pincode veilig genoeg is voor jouw bankpas, is dat na 3 foute pogingen verdere toegang wordt geblokkeerd. Bankpassen hebben echter weinig of geen last van DoS aanvallen (omdat de aanvaller dat ding al in handen moet hebben, en dan is een blokkade juist gewenst). Bij een internet-connected device zijn DoS aanvallen wel een realistisch probleem. Aanvulling: de DoS is dan een onbedoelde bijwerking van het proberen van verschillende wachtwoorden met een (meestal tijdelijke) account-lockout als gevolg, die er ook toe leidt dat de rechtmatige eigenaar niet meer kan inloggen. Ik bedoel dus geen opzettelijke DoS aanvallen - hoewel die natuurlijk ook denkbaar zijn op het moment dat een inbreker met een koevoet naar je voordeur loopt.

Wellicht is de baas van Ring banger voor imagoschade t.g.v. ontoegankelijke "altijd thuis, ook in het buitenland" deurbellen dan voor imagoschade als gevolg van gehackte exemplaren (wellicht omdat ze hopen dat sterke wachtwoorden geen wishful thinking zijn en/of ze daar hun "stomme" klanten de schuld van kunnen geven). En mogelijk hebben ze daarom voor een strategie met trage of geheel geen account lockout gekozen (ik speculeer slechts), waardoor brute-force aanvallen op afstand relatief eenvoudig en met succes kunnen worden uitgevoerd. Maar er kan ook sprake zijn van een bug waarbij informatie wordt gelekt of je dichter bij of verder weg bent van het juiste wachtwoord (bijv. een foutmelding bij een onjuist wachtwoord die sneller gegeven wordt als de lengte van het gegeven wachtwoord wel klopt).

Er is dan maar één remedie (die altijd verstandig is, naast het niet kopen van junkware en het ASAP installeren van beschikbare updates): gebruik een niet te raden, lang wachtwoord. Mijn advies voor dit soort devices: laat je wachtwoordmanager een zo lang mogelijk (nog toegestaan door het device) random wachtwoord genereren en voor je onthouden, en zorg voor minstens twee kopiën op verschillende plaatsen van de -versleutelde- wachtwoorddatabase - met daarin natuurlijk ook de allerlaatste wijzigingen.

Ga toch weg man, het is hier geen dumpert.
Als je geen engels wil lezen, zit je in het verkeerde vakgebied.

Engels

De monitoring van alle medewerkers bij Ring gaat kennelijk zeer ver.
Als er geen vaste procedures zijn met een onderbouwde reden om naar iets te kijken dan is dit bijvangst.

Ik zou niet weten hoe je normale benaderingen normale gedragingen moet profileren om op zoek te gaan naar de echte (obekende) bedreigingen. Dat lijkt me nu het werk van beveiliger.

Ja ik heb dat woord sleepnet gebruikt omdat die gebruikt is om dat willen kunnen beveiligen als ongewenst te framen.
De aivd positioneren als de politie die dan ook.nog een iedereen zijn gangen sil volgen is geen goede insteek. Intussen is die wet er toch door en blijkt beter te zijn dan de voorgaande.

Je weet dat op endpoint het password niet gencrypt wordt geen hash en geen salt. Daarom heeft men de eis van een beveiligde verbinding ingevoerd zodat die over de lijn niet leesbaar is.
Ook het verhaal dat anddre programmatuur mogelijk kan meekijken geeft dat aan.

Het password komt leesbaar aan de andere kant over.
Dat is het moment dat controles met iets anders mogelijk is. Daaronder valt een controle of het elders in gebruik is.
Daarna komt de hash met salt stap om te vergelijken met een opgeslagen waarde. Als het anders zit, gaarne onderbouwing met referenties. https://security.stackexchange.com/questions/171970/hash-salt-and-best-practices

Wat nog erger is dat ze het verkopen voor meer dan 100 euro per stuk en nog ook zo omgaan met je privacy. Dus made in china troep is veiliger.

Ze kijken ook mee in Nederland

HOE DOM KAN JE ZIJN? Je denkt dat een site ermee weg zou komen door op jouw computer (want dat is het 'endpoint' hier in deze context) te gaan controleren of het plaintext wachtwoord dat jij gebruikt op andere plaatsen (sites) van derden wordt gebruikt? En dat schrijf je - met nauwelijks verholen trots - nog neer ook? Helaas voor jou kan je berichten niet meer verwijderen op deze site dus deze blamage is voor de eeuwigheid.

Trouwens idem voor als men op de server dit soort controles zou doen voordat het password versleuteld wordt. Ook not done!

Dat geldt ook voor jouw bericht.

Hashes van gecompromiteerde wachtwoorden op bijv. haveibeenpwned.com zijn in (unsalted) SHA-1 formaat. Zoals je zelf wel zult weten is het verhaspelen van in gebruik zijnde wachtwoorden (d.w.z. door login-functies op servers) in SHA-1 formaat, in jouw woorden, "not done" en wordt hopelijk een algoritme zoals Argon2 gebruikt.

Echter, zodra je een wachtwoord met Argon2 of zelfs salted SHA-1 hebt verhaspeld, kun je niet meer checken of het voorkomt in een lijst met unsalted SHA-1 hashes van veel gebruikte wachtwoorden. Daarvoor zul je toch echt dat plain text wachtwoord ook naar een SHA-1 hash moeten omzetten, om te kunnen checken of die hash voorkomt in die lijst.

Ik ga niet bakkeleien wie van jullie gelijk heeft, maar zou jullie beiden vriendelijk willen vragen om voortaan op basis van steekhoudende en verifieerbare argumenten te discussiëren, in plaats van op de man te spelen. Veel lezers en duidelijk ook de redactie zijn namelijk helemaal klaar met jullie gedrag, het soort waarvan ouders zeggen: "dat wordt huilen".

In elk geval ik baal ervan als ik veel tijd besteed aan een doordachte bijdrage en ik daar vervolgens niet eens antwoord op krijg van de vragensteller - wellicht omdat mijn bijdrijge is ondergesneewd met een reeks wellis/nietes/taalgeneuzel bijdragen en/of met persoonlijke verwijten, waar letterlijk niemand wijzer van wordt.

Kunnen we het alsjeblieft gezellig houden, en zo niet, op z'n minst zakelijk? En als een mening onwrikbaar lijkt: niet reageren kan ook!

Nee.


Wie trekt dat in twijfel dan? (Ik in ieder geval niet.)


Ja duh... Men dient echter zo veel mogelijk met z'n poten van het plaintext wachtwoord af te blijven, het zo snel en zo 'laag' mogelijk door de one-way versleuteling te gooien en de plaintext te wissen! Als je met de plaintext gaat lopen 'zeulen', om het bv. te controleren op veelgebruikt, e.d. dan introduceer je - of op z'n minst vergroot je - alleen maar de kans dat het wordt afgekeken. Not done dus. Dan maar geen controle op 'vaakgebruikt'.

@Erik van Straten En v.w.b. de rest van je verhaal: eenzijdige censuur en selectie geeft scheve gezichten, steeds feller wordende reacties, weglopen van bezoekers, etc.

Jouw standpunt is duidelijk. En daarom was dit mijn laatste reactie op bijdragen van jou (ik hoop dat je niet zo'n laffaard bent die steeds zijn/haar pseudoniem wijzigt).

Mijn standpunt is duidelijk en daarom reageer je niet meer? Rare gedachtengang en inhoudelijk ga je niet in op de rationale voor mijn opmerking hierboven. Maar goed... Ik wijzig mijn pseudoniem en zelfs accounts best veel, naargelang landelijke en security.nl trends. Daar ga ik echt niet van afwijken om zo'n rare verkeerd gespelde opmerking van jou - want het maakt me niet uit wat jij (daarvan) vindt. Dus tot ziens ;-)

Omdat je lijkt te proberen constructief bij te dragen in mijn topic "Secure SMS 2FA proposal", en ik een hekel heb aan ruzie (vooral langdurige), het volgende. Ik vind dat je onwrikbare en onrealistische standpunten inneemt. Dat mag, maar dan heeft het geen zin om te discusiëren.

Wat met vooral stoorde (ik hoop dat dit tot het verleden blijft behoren) is dat je op de man speelt vooral m.b.t. de duidelijke handicap van karma4; dat is ordinair online pesten. Jammer dat je ook mij aanvalt op spellings/taalfouten (ik dacht overigens echt dat je lafaard met ff schreef, omdat je het anders als laafaard uit zou kunnen/moeten spreken - weer wat geleerd, maar de manier waarop vind ik jammer).

Kortom, ik respecteer jouw standpunten maar ga niet meer met jou in discussie over welk OS dan ook op de desktop. En vooral hoop ik dat je niet meer op de man speelt, want dat is onnodig kwetsend, terwijl ik (en vermoedelijke vele andere lezers) jou dan de grootste verliezer vinden.

Let's agree to disagree.


Je snapt hopelijk dat wanneer je het woord lafaard gebruikt dat je dan een enigszins fel weerwoord kan verwachten?


Ik mag zelf graag denken dat ik dat pas doe wanneer anderen ermee begonnen zijn (denigrerende opmerkingen, etc.). Oog om oog, tand om tand, en zo. Maar op zich heb je gelijk natuurlijk en is het gewoon not done.

OK.

Daar heb je een punt. Ik was geirriteerd en dan schiet ik soms door, sorry. Maar je zult ook moeten toegeven dat als je iemands bijdragen niet meer wilt lezen, het handig is als de persoon in kwestie niet telkens van alias wijzigt (iets dat we karma4 in elk geval niet kunnen verwijten).

B.t.w. Erik van Straten is mijn echte naam (niet uniek, maar als je mijn naam tussen " " googled in combinatie met security, krijg je een aardig beeld). Ik begrijp heel goed dat ik een risico neem door onder mijn echte naam te posten. Zo heb ik geruime tijd niet meer onder mijn naam bijgedragen nadat iemand, in een discussie, kennelijk geen andere argumenten kon bedenken dan iets vergelijkbaar met "zorg jij nou maar dat alles bij jouw werkgever X veilig is" - een werkgever die het een goed idee vond om mijn naam en foto te publiceren in relatie tot het bedrijf, iets waar ik nu nooit meer akkoord mee zou gaan (behalve dat het mij beperkingen oplegt, vormt het ook een risico - zeker voor bedrijven gerelateerd aan security). Daar komt bij dat je als medewerker wel invloed kunt uitoefenen, maar uiteindelijk niet de beslissingen neemt. Oftewel: (werknemer != bedrijf) && (bedrijf != werknemer).

Banen zijn niet 24x7 en ook niet meer levenslang, mijn identiteit is dat wel. Ik spreek hier voor mijzelf en niet voor welke werk/opdrachtgever dan ook (logischerwijze vermijd ik werkgerelateerde onderwerpen of ben daar uiterst voorzichtig mee, in de zin van dat ik geen gebruik maak van vertrouwelijke informatie die ik heb als gevolg van de betreffende werkzaamheden).

Jammer dat het de cultuur is dat we onze identiteit moeten verhullen omdat we bang zijn voor de consequenties, mocht iemand het niet met ons eens zijn.

Wat mij betreft zand over ons dispuut :-)

Snap ik ook ja. N.B.: het wisselen van account is niet altijd vrijwillig geweest (en terecht want dan was ik wat doorgeschoten). Voor wat betreft op de man spelen krijg je natuurlijk ook dat mensen geïrriteerd op mij gaan reageren omdat ze andere felle posts hebben gelezen, dus ook al denk ik oog om oog, tand om tand, uiteindelijk blijft mijn felle reageren meer hangen dan de context waarin. Moet ik afleren dus.


Ik heb er zelf in het verleden veel gedonder mee gehad dus ik ben nu zo veel mogelijk anoniem op internet.


Wat mij betreft ook :-)

Thanks!