Netflix controleert of wachtwoorden gebruikers voorkomen in recente grote hacks

+1 .GoO
7 juni 2016 07:55

De afgelopen 4 weken zijn er verschillende personen vanuit Argentinië, Peru, etc. ingelogd geweest op mijn account. Ze waren zelfs zo brutaal om de taal van mijn account op Spaans te zetten en mijn abonnement te verhogen zodat er meer mensen tegelijk konden kijken.

Na een eigen wachtwoord reset lijkt het nu opgelost. Geen idee hoe ze aan mijn gegevens zijn gekomen, ik heb ze in ieder geval niet rond laten slingeren. Ik heb wel een LinkedIn account, maar niet met hetzelfde wachtwoord. Ben wel benieuwd of er meer mensen met dezelfde ervaring zijn.

+2 MR.Harok
@.GoO • 7 juni 2016 08:22

Je kan op https://haveibeenpwned.com/ controleren of je bij hacks zat en wat er is buitgemaakt. Zo is er ook de Adobe hack uit 2013 waar veel nl combo's zijn buitgemaakt.

+1 Mr.Skippie
@MR.Harok • 7 juni 2016 08:52

Ik heb m'n reservaties bij dergelijk sites.

+2

Yggdrasil

@Mr.Skippie • 7 juni 2016 09:33

Dat is verstandig. Alleen is deze van beveiligingsonderzoeker Troy Hunt en die heeft naar mijn mening wel bewezen op een nette manier met dit soort gegevens om te gaan.

Daarnaast geef je alléén je e-mailadres in en dat kun je niet echt een zeer gevoelig persoonsgegeven noemen, aangezien je het o.a. gebruikt als inlognaam op tientallen of honderden sites.

In dit geval vind ik de geleverde dienst, het ontdekken van lekken van mijn data, waardevoller dan mijn e-mailadres.

+1

friend
@Yggdrasil • 7 juni 2016 11:32

Daarom is het ook verstandig om voor 15 euro per jaar een eigen domein te nemen, met email forwarding. Zo kan je voor elke site een eigen email adres gebruiken. Dan weet je ook gelijk wat de welke site verantwoordelijk is als je spam ontvangt. En het scheelt ook als je een keer van provider veranderd, dan hoef je ook je email niet te veranderen.

+2

Bartske
@friend • 7 juni 2016 11:40

Dat kan met gmail ook. Als je emailadres naam@gmail.com is kan je bijvoorbeeld voor dropbox naam+dropbox@gmail.com invullen en het komt automatisch in je mailbox. Stuk simpeler dan de oplossing die jij geeft.

https://support.google.com/mail/answer/12096?hl=en

[Reactie gewijzigd door Bartske op 7 juni 2016 11:41]

+1

Coffee

@Bartske • 7 juni 2016 11:45

Als ik dit zou willen toepassen, moet ik dan in het email adres het plus teken gebruiken, of moet ik het er gewoon achter typen?

Ik weet wel dat bij het aanmelden op gmail er geen rekening gehouden wordt met punten. Je kunt dus net zo goed aanmelden als C.o.f.f.e.e@gmail.com als coffee@gmail.com (niet dat ik dat mail adres heb, maar het gaat om het voorbeeld).

+1 Bart.net
@Coffee • 7 juni 2016 14:58

coffee+linkedin@gmail.com

Dit heb ik tijdelijk gebruikt voor een paar websites.
Nadeel is dat ik bij mediamarkt me wel kon inschrijven met dit adres, maar ik mocht me niet meer uitschrijven omdat hij het niet meer herkende.
Ander nadeel is dat plussen en punten er heel makkelijk uit te filteren zijn.

+1 SaiKoTiK
@Bart.net • 7 juni 2016 16:13

En dat om te controleren of je pwned bent (haveibeenpwned.com) je dan voor elke +combinatie appart moet gaan checken.

+1

armageddon_2k1
@Bartske • 7 juni 2016 11:43

Ja, met de nogal grote kanttekening dat vrij veel sites een '+' in het email-adres, hoe geldig ook, niet accepteren. Dan kan het simpeler zijn, maar als het niet geaccepteerd is schiet je er niks mee op.

Daarnaast heeft ook niet iedereen Gmail

+1

Bartske
@armageddon_2k1 • 7 juni 2016 11:45

Voor die sites kun je ook n.aam@gmail.com of na.am@gmail.com gebruiken, moet je wel onthouden of opschrijven voor welke site je welke alias gebruikt hebt.

Daarnaast kun je gmail gewoon gratis aanmaken en evt forwarden naar je huidige email

Vraag is of je al je mail aan google wil 'geven', maar dat is een andere discussie.

+1 W.Wonderland
@Bartske • 7 juni 2016 11:49

Goede oplossing maar een probleem met gmail is alleen dat iedereen weet dat je de punten en het gedeelte achter de + kan weglaten.
Hierdoor komt de mail toch aan en kan je het niet traceren of blokkeren.
Bovendien accepteren niet alle sites een + in het email adres.
Het is de goedkoopste en simpelste oplossing maar er zitten helaas dus een paar nadelen aan.
(zelf heb ik meerdere email adressen afhankelijk van mate van vertrouwen (icm de + en punten))

[Reactie gewijzigd door W.Wonderland op 7 juni 2016 11:51]

+1

friend
@Bartske • 7 juni 2016 13:03

Spammers weten dat ook en kunnen eenvoudig die toevoeging eruit filteren. En je zit dan aan gmail/Google vast. Eigen domein en email forwarding is heel eenvoudig en je hebt alles in eigen hand.

+1

glaasjejus
@Bartske • 7 juni 2016 13:54

Deze truc is natuurlijk bekend bij zowel spammers die hun bronnen niet willen prijsgeven alsook louche sites die hun gebruikers verkopen. Die strippen het + gedeelte er gewoon tussenuit.

0 jerisson
@glaasjejus • 8 juni 2016 00:15

Wat betreft spam kan je dat eenvoudig oplossen. Als je email-adres bijvoorbeeld voornaam.achternaam@gmail.com is (dus met een punt), dan kan je bijvoorbeeld v.oornaam.achternaam+site@gmail.com opgeven (extra punt). Bij het strippen van de + blijft de extra punt over waardoor je alsnog kan filteren. En ook als de punten verwijdert worden kan je eenvoudig filteren. Eventueel kan je ook een whitelist van geldige ontvangers aanmaken om te voorkomen dat andere combinaties gebruikt worden.

Wat mij meer stoort aan dit systeem (+ en .) is dat het geen ge standaardiseert systeem is en de meeste mensen het dus ook niet kennen. Zo heb ik ooit een bestelling geplaatst bij een webshop met +sitenaam aan mijn email-adres toegevoegd. Een paar maanden en bestellingen later werd ik opgebeld om te vragen of dat adres wel klopte (want het is toch vreemd dat onze naam daar in staat...).

0

Blizz
@Yggdrasil • 7 juni 2016 20:24

Daarnaast geef je alléén je e-mailadres in en dat kun je niet echt een zeer gevoelig persoonsgegeven noemen, aangezien je het o.a. gebruikt als inlognaam op tientallen of honderden sites.

Hoe afhankelijker je bent van één e-mailadres of username, hoe gevoeliger het gegeven is

+1

Vayra
@Mr.Skippie • 7 juni 2016 10:24

Als het je een beter gevoel geeft: ik zag drie 'breaches' en alledrie waren ze 100% plausibel en accuraat.

+1

holhuizen
@Vayra • 7 juni 2016 11:01

Heb het zelf net ook ff getest, en de website werkt goed!
Blijkbaar is het webhost bedrijfje waar ik ook eens een site heb gemaakt gehackt geweest, waar ik ook nooit een melding van gekregen heb.

edit:
idd 000webhost
net even in mijn email gezocht, kan niet 123 een berichtje vinden waarin dit verteld is, maar ik neem dan aan dat ze dat toch wel gedaan hebben, in ieder geval wist ik het niet.

[Reactie gewijzigd door holhuizen op 7 juni 2016 12:28]

+1

StrongArmLance
@holhuizen • 7 juni 2016 11:12

Bedoel je 000webhost? Die hebben namelijk wel degelijk 'excuus mails' rondgestuurd.

+1

Coffee

@StrongArmLance • 7 juni 2016 11:46

Via hun ben ook ik 'gepwnd'..
Ik kan me niet meer herinneren dat ik dat ooit een site had gemaakt, maar nu ik toch voor alle (belangrijke) sites en uniek ww heb vindt ik het niet zo erg

[Reactie gewijzigd door Coffee op 7 juni 2016 11:47]

+1 FuaZe
@holhuizen • 7 juni 2016 11:08

Ah, ik wist niet dat ook kleine hacks hierin voorkwamen. Maar de meeste kleine bedrijven zijn niet zo van het notificaties sturen bij een hack, heb zo het idee dat die het liever voor zichzelf houden.

0 MarcoC
@Mr.Skippie • 7 juni 2016 11:02

Ik neem aan dat je "bedenkingen" bedoelt.

0 Mr.Skippie
@MarcoC • 7 juni 2016 12:22

Engels is m'n "main language", soms is het moeilijk een correcte vertaling te vinden.

+1 atlaste
@MR.Harok • 7 juni 2016 08:51

Mooie website. Mijn spam-adres was inderdaad gepwned

Op zich was dat te verwachten

Wel bijzonder onprettige dingen die ik daar allemaal lees over de beveiliging van grote websites. Een paar voorbeeldjes:

LinkedIn: In May 2016, LinkedIn had 164 million email addresses and passwords exposed. Originally hacked in 2012, the data remained out of sight until being offered for sale on a dark market site 4 years later. The passwords in the breach were stored as SHA1 hashes without salt, the vast majority of which were quickly cracked in the days following the release of the data.

Adobe: In October 2013, 153 million Adobe accounts were breached with each containing an internal ID, username, email, encrypted password and a password hint in plain text. The password cryptography was poorly done and many were quickly resolved back to plain text. The unencrypted hints also disclosed much about the passwords adding further to the risk that hundreds of millions of Adobe customers already faced.

MySpace: In approximately 2008, MySpace suffered a data breach that exposed almost 360 million accounts. In May 2016 the data was offered up for sale on the "Real Deal" dark market website and included email addresses, usernames and SHA1 hashes of the first 10 characters of the password converted to lowercase and stored without a salt. The exact breach date is unknown, but analysis of the data suggests it was 8 years before being made public.

Serieus mensen, wachtwoorden hashen zonder salt?

Wachtwoorden opslaan die om te zetten naar plain text?

Dit soort praktijken moeten wmb. gewoon fikse boetes op komen, zo maak je het hackers wel heel erg makkelijk. Bedrijven als Adobe, MySpace en LinkedIn hebben alle mogelijke resources om dit gewoon goed te doen!

+1

cracking cloud
@atlaste • 7 juni 2016 09:37

Zie ook plaintextoffenders.com voor nog meer wtf

+1

Bender
@cracking cloud • 7 juni 2016 10:44

Zijn er werkelijk nog partijen die dit doen???

+1

cracking cloud
@Bender • 7 juni 2016 12:17

Kennelijk

+1 StefanTs
@Bender • 7 juni 2016 14:16

Ik kreeg een paar maanden terug nog een paswoord toegemaild van het college voor toetsen en examens toen ik deze wilde resetten. Dus mocht je nog wat rekentoetsen willen saboteren, de beveiliging van Facet is in ieder geval op een plek al lek.

0

Tribits
@StefanTs • 7 juni 2016 15:22

Er bestaat een leuke website die als doel heeft om sites die passwords als plaintext of met reversible encryptie opslaan (niet veel beter) aan de schandpaal te nagelen: Plain Text Offenders.

@StefanTs, heb even zitten slapen zie ik

[Reactie gewijzigd door Tribits op 7 juni 2016 16:20]

0 StefanTs
@Tribits • 7 juni 2016 16:09

Klopt, zie 2 reacties hierboven

0

jp
@cracking cloud • 8 juni 2016 08:34

Ik vind het overigens nogal een verschil als je een account aanmaakt dat je een mailtje krijgt met login+password (want op het moment dat het account aangemaakt wordt weet de webserver het unencrypted wachtwoord), of dat je het oorspronkelijke wachtwoord toegestuurd krijgt als je aangeeft dat je je wachtwoord vergeten bent. (Want dan wordt het daadwerkelijk unencrypted opgeslagen.)

0

cracking cloud
@jp • 8 juni 2016 09:08

Je wachtwoord wordt op dat moment plain text over internet verstuurd en verdwijnt in een inbox. Ik vind het zelf niet zo'n veilig idee.

+1

timvisee
@atlaste • 7 juni 2016 09:32

Mee eens.
Bij veel sites wordt er bij de initiële development totaal niet nagedacht over beveiliging, als we spreken over wachtwoorden. Om dat later aan te passen is vaak een gedoe bij een onflexiebek systeem, of er wordt niet eens over nagedacht. Dat zegt mijn ervaring tenminste.

Belachelijk eigenlijk.

+1

xleeuwx

@atlaste • 7 juni 2016 10:55

ik wilde net mijn wachtwoord wijzigen op een website en daar kreeg ik netjes mijn oude wachtwoord samen met mijn gebruikersnaam gemaild.

Verder is dit gewoon een IT website ...
http://thinware.net/

[Reactie gewijzigd door xleeuwx op 7 juni 2016 10:57]

+1 Morelleth
@MR.Harok • 7 juni 2016 08:43

Goede, die kende ik nog niet.
Blijkbaar inderdaad naast LinkedIn (die netjes gemeld was) ook Adobe (nooit een melding gehad) en een oude HoN account (ook nooit gemeld).

+1

Centelte
@Morelleth • 7 juni 2016 09:50

Netjes gemeld? Ze melden het 4 jaar te laat...

+1 Morelleth
@Centelte • 7 juni 2016 12:19

Ja dat dan weer wel.
Maar hoe wil je weten welke adressen getroffen zijn als je niet welke info in handen is?
Volgens mij was 4 jaar geleden toch ook gemeld dat ze gehackt waren?

Nou ja. Liever laat dan nooit. Gebruik in elk geval overal een uniek wachtwoord dus heel veel last heb ik er niet van.

+1

Centelte
@Morelleth • 7 juni 2016 17:40

Ze hadden gezegd dat op zijn minst sommige wachtwoorden gehackt waren. Terwijl ze hadden kunnen weten dat de hackers toegang hadden tot alle wachtwoorden. Maar dat hadden ze niet aan de gebruikers gemeld. Ze hadden alle accounts een email moeten sturen om hun wachtwoord aan te passen, wat ze nu ook gedaan hebben, maar dan 4 jaar geleden.

Ook waren de wachtwoorden enkel in SHA1 ge-encrypt, zonder salting. Die fout hadden ze gewoon niet kunnen maken. (in mijn opinie)

+1

GekkePrutser

@MR.Harok • 7 juni 2016 11:45

Bedankt! Mijn paswoord op linkedin zat er dus ook bij

Gelukkig gebruikte ik die nergens anders voor zover ik weet.

Wel super slecht van Linkedin dat ze er geen enkele melding van maken bij het inloggen of je manen je wachtwoord te veranderen. Voor een 'professionele' site zeer klungelig gedaan.

+1

satoer
@GekkePrutser • 7 juni 2016 17:34

Ik kreeg anders deze mail van Linkedin. Waarschijnlijk heb je die over het hoofd gezien:

Notice of Data Breach

You may have heard reports recently about a security issue involving LinkedIn. We would like to make sure you have the facts about what happened, what information was involved, and the steps we are taking to help protect you.

What Happened?

On May 17, 2016, we became aware that data stolen from LinkedIn in 2012 was being made available online. This was not a new security breach or hack. We took immediate steps to invalidate the passwords of all LinkedIn accounts that we believed might be at risk. These were accounts created prior to the 2012 breach that had not reset their passwords since that breach.

What Information Was Involved?

Member email addresses, hashed passwords, and LinkedIn member IDs (an internal identifier LinkedIn assigns to each member profile) from 2012.

What We Are Doing

We invalidated passwords of all LinkedIn accounts created prior to the 2012 breach that had not reset their passwords since that breach. In addition, we are using automated tools to attempt to identify and block any suspicious activity that might occur on LinkedIn accounts. We are also actively engaging with law enforcement authorities.

LinkedIn has taken significant steps to strengthen account security since 2012. For example, we now use salted hashes to store passwords and enable additional account security by offering our members the option to use two-step verification.

What You Can Do

We have several dedicated teams working diligently to ensure that the information members entrust to LinkedIn remains secure. While we do all we can, we always suggest that our members visit our Safety Center to learn about enabling two-step verification, and implementing strong passwords in order to keep their accounts as safe as possible. We recommend that you regularly change your LinkedIn password and if you use the same or similar passwords on other online services, we recommend you set new passwords on those accounts as well.

For More Information

If you have any questions, please feel free to contact our Trust & Safety team at tns-help@linkedin.com. To learn more visit our official blog.

0

GekkePrutser

@satoer • 7 juni 2016 17:45

Oh ja nu ik er op zoek zie ik hem. De combinatie "LinkedIn" en "Legal" was genoeg om hem niet te openen. De subject geeft ook niet aan dat het over de breach ging. Ik dacht waarschijnlijk dat het om aangepaste gebruiksvoorwaarden ging of andere juridische flauwekul.

Bovendien, mijn paswoord stond op die lijst en is in de tussentijd nooit veranderd. Toch hebben ze het niet geblokkeerd of krijg ik zelfs geen melding bij het inloggen. Terwijl ze weten dat dat paswoord op straat ligt. Volgens de email hebben ze de gelekte paswoorden wel geblokkeerd maar ik weet zeker dat ik mijn paswoord al sinds ver voor 2012 heb. Ook zat mijn paswoord volgens die https://haveibeenpwned.com/ site bij de gelekte gegevens.

Ik heb het inmiddels veranderd maar ik blijf het een waardeloze reactie vinden van Linkedin.

0 Pietervs
@GekkePrutser • 7 juni 2016 19:12

4 jaar geleden was al bekend dat er een grote hack was van LinkedIn. En ook toen kon je opzoeken of jouw account-gegevens ook waren buitgemaakt (ik "mocht" toen ook mijn wachtwoorden resetten

).

Zelf mag je ook wel enige actie ondernemen als je hoort dat er een site gehacked is waar jij een account hebt. Alleen maar afwachten of je bericht krijgt is natuurlijk te gemakkelijk.

+1 jesse111
@MR.Harok • 7 juni 2016 11:49

Helaas is haveibeenpwned niet volledig.

Er zijn veel meer hacks geweest en die zijn niet altijd terug te vinden bij haveibeenpwned.
Ik had laatst even gekeken hoe vaak ik voorkwam in de lijst op haveibeenpwned, maar kwam daar geen een keer in voor.

Toen ik keek op https://www.leakedsource.com/ kon ik mezelf wel een aantal keer terug vinden in hacks.

Wat je het beste kan doen is gewoon zorgen dat je voor elke website een ander wachtwoord hebt. Een password manager is echt ideaal hiervoor.

+1

Tijgertje

@MR.Harok • 7 juni 2016 14:44

Interessante link. Mijn e-mailadres staat er gewoon 4 keer tussen. En ook daadwerkelijk 4 websites waar ik geregistreerd sta, hmm..

0 Jorgen
@MR.Harok • 7 juni 2016 09:18

Volgens die website zou mijn e-mailadres 1 x voorkomen in een lijst met buitgemaakte wachtwoorden, maar de betreffende website heb ik zover ik weet helemaal geen account voor. Ik kan het in elk geval niet vinden en met de wachtwoord-vergeten-optie op diezelfde website wordt mijn e-mailadres niet herkend. Vaag gebeuren dus.

+2 laydne
@.GoO • 7 juni 2016 09:28

Zelf ook gehad en zelfs op een gegeven moment wachtwoord en mail aangepast, je hoeft er blijkbaar niet te comfirmen dat je mail is gewijzigd, heb contact gehad en zij hebben alles terug gezet voor mij maar wel gewaarschuwd dat de volgende keer ik een nieuw account moet aanmaken

Was ook inderdaad Spaans en hadden het inderdaad ook verhoogd, er is een grote hack geweest en zoals er al wordt gezegd check https://haveibeenpwned.com, daar zal je hoogwaarschijnlijk jou account op terug vinden, bij mij was het gebeurd vlak nadat ik mijn netflix wachtwoord terug gezet had naar een oud wachtwoord van mij, dus wel van geleerd

+1

noiz13
@.GoO • 7 juni 2016 11:28

Krijg je geen mailtje van netflix als er een nieuw apparaat inlogd?

+1 .GoO
@noiz13 • 7 juni 2016 12:06

De laatste keer wel, maar de weken daarvoor heb ik hier geen mail van gehad.

+1

RoyK
@.GoO • 7 juni 2016 09:52

Door jouw bericht ben ik ook eens gaan kijken en zie dat er 4x ingelogd is vanuit de UK. Ik sta er even van te kijken!

0 Sjoan
@RoyK • 7 juni 2016 10:17

Waar kan je dat zien?

+1

RoyK
@Sjoan • 7 juni 2016 10:30

je kan even uit mijn hoofd zien in je account met welke apparaten je ben geloogd de afgelopen tijd. Daar staat ook een land en ip bij.

0

shadow4thedark
@RoyK • 7 juni 2016 11:01

Op chrome kan ik het niet vinden. Kan je geen printscreen maken?

+2

RoyK
@shadow4thedark • 7 juni 2016 11:18

Netflix inloggen

- Mijn account

Dan bij mijn account zie je:

- Kijkactiviteit

Bovenin zie je "Recente toegang tot account bekijken"

En daar zag ik het inloggen vanuit de UK tussen staan. En in de lijst bekeken series staan dingen tussen die ik niet heb gekeken. Voelt raar hoor.

Middels heb ik mn wachtwoord aangepast (en die was hiervoor gewoon uniek)

+1 acst
@shadow4thedark • 7 juni 2016 11:21

mijn profiel -> kijkactiviteit -> Recente toegang tot account bekijken (staat bovenin die pagina in het blauw)

+1

BdK9001

@.GoO • 7 juni 2016 07:58

Same here, ik was er niet achter gekomen als er niet ineens "Andrés" als 4e gebruiker bij was gekomen naast mij, mijn vriendin een een vriend van me. Toen toch maar even wachtwoordje gewisseld. Kwam volgens mij uit de linkedin-hack.

+1 mgizmo
@.GoO • 7 juni 2016 07:59

Teamviewer standaard actief op een desktop?

+1

ACM
@.GoO • 7 juni 2016 08:01

't Zou natuurlijk nog kunnen dat je een eenvoudig te raden wachtwoord had, waardoor ze er op die manier bij konden komen? Of dat het eenvoudig af te leiden was van je linkedin wachtwoord?

+1

Sabes
@.GoO • 7 juni 2016 08:48

Bij het account wat op naam van mijn vrouw staat ook eens voorgekomen.
Ik kon ineens niet meer inloggen want het wachtwoord werkte niet. Met de optie wachtwoord vergeten kwamen we ook niet verder. Totdat mijn vrouw ineens zei dat ze wel een beetje een rare e-mail van Netflix had ontvangen, ze kon het niet lezen.

Ik die mail lezen en zag dat het in het portugees was (dacht eerst spaans, maar goed).
Uiteindelijk heeft ze de volgende dag gebeld met het servicenummer en daar konden ze zien dat er ingelogd was in Brazilië en het account ook was gewijzigd, inclusief inlog.

Dit hebben ze teruggedraaid. Wijze les voor mijn vrouw om wat aan haar wachtwoorden te doen.

0 harrytasker

@.GoO • 7 juni 2016 11:35

Als ik het goed begrijp dan weet Neflix je wachtwoord?

0 Durandal
@harrytasker • 7 juni 2016 14:45

Je begrijpt het niet goed.
Netflix weet de hash van je wachtwoord.

Die vergelijken ze dan met de hashes van de gestolen wachtwoorden.

0

tijm15
@.GoO • 7 juni 2016 15:33

Mijn netflix account was 2 weken geleden gehacked vanuit Frankrijk. Kreeg eerst een mail of ik een gebruiker in Frankrijk toegang wilde verlenen en daarna een mail dat mijn emailadres was aangepast. Toen kon ik dus niet meer in mijn account komen. Meteen netflix gebeld en alles aangepast. Ik heb ook geen idee hoe ze aan mijn gegevens zijn gekomen.

+1

sanderev66

7 juni 2016 07:53

Dit zouden meer websites moeten doen.

+2

koku
@sanderev66 • 7 juni 2016 09:58

Het probleem is alleen dat je niet zomaar aan de gelekte gegevens komt. De data van de LinkedIn hack is niet via torrent oid te bemachtigen, maar is alleen te koop met bitcoins op een Dark Web website. Ik voel er niet zoveel voor om 2500 euro aan bitcoins uit te geven voor een gelekte database. Hoe Netflix aan die data komt weet ik niet, maar misschien hebben zij goede connecties met Troy Hunt of hebben ze daadwerkelijk bitcoins uitgegeven?

Alternatief is via de betaalde api van leakedsource.com, maar dat is eigenlijk geen optie, omdat je dan de e-mailadressen van je gebruikers moet doorgeven aan LeakedSource.

Een andere mogelijkheid is dat iemand ons benaderd en de database geeft, voor het goede doel zeg maar

+1

Tribits
@koku • 7 juni 2016 14:15

Een andere mogelijkheid is dat iemand ons benaderd en de database geeft, voor het goede doel zeg maar

Mogelijk worden de databases achter de schermen ook wel gedeeld nadat ze eenmaal in handen zijn gekomen van een partij die ze voor legitieme doelen gaat gebruiken. Zal echter nog steeds wel de vraag blijven in hoeverre het verder verspreiden van dergelijke databestanden in overeenkomst is met de wet bescherming persoonsgegevens. Je bent dan opeens in het bezit van grote hoeveelheden data van gebruikers die zich nooit aan hebben gemeld voor jouw site/project.

0

koku
@Tribits • 7 juni 2016 17:53

Ja dat klopt inderdaad. Maar bedrijven als Facebook en Netflix zien na zo'n hack het aantal overgenomen accounts sterk toenemen en dit is een manier om dat tegen te gaan. Daarnaast heb je nog verschil tussen het aanbieden van zo'n database of het verkrijgen van zo'n database. Maar het is zeker een grijs gebied.

Op het moment dat deze database makkelijker te verkrijgen is via internet, zullen waarschijnlijk meer sites hetzelfde gaan doen, want het aantal account overnames zal ook flink toenemen dan, gok ik.

0 Toryu
7 juni 2016 07:57

Geen expert hier, maar volgens mij betekent dit dat Netflix geen unieke salt per gebruiker heeft. Dus dat is wel degelijk onveilig.

+1 Royvs33
@Toryu • 7 juni 2016 08:02

nee, dat betekent dit niet, ze gaan eigenlijk proberen in te loggen met elke user&pass combinatie die ze op internet vinden en als ze ermee in kunnen loggen dan laten ze dat weten. Een salt maakt voor dit niks uit(aangezien een salt bijna altijd van de gebruikersnaam afkomt)

+1

Standeman

@Royvs33 • 7 juni 2016 08:55

Dat hoop ik niet zeg. Een salt is een is een random 64 of 128 gegeneerde waarde. Met alleen een gebruikersnaam kan je alsnog rainbowtables gebruiken.

+2 Niemand_Anders

Beheer en beveiliging

@Standeman • 7 juni 2016 10:25

Hoe lang de precies salt is, kan niemand behalve degene welke de implementie heeft gedaan zeggen. Een salt is slechts 'random' data welke wordt toegevoegd aan het password. Tegenwoordig worden salts vooral gebruikt als 'key' voor een message digest algoritme zoals HMACSHA1. Hierbij is jouw wachtwoord de data en de salt de key.

HMACSHA1 heeft bijvoorbeeld een blocksize van 64 bytes. Dat betekend dat als de implementator bijvoorbeeld slechts 32 bytes aan random data ophaalt (64 bytes in hex, echter slechts de helft van de blocksize), de key wordt opgevuld met padding data. Over het algemeen null bytes.

Bij het gebruik van een HMAC algoritme dient de hoeveelheid random data een velvoud van de key blockSize te zijn. Anders wordt de key verzwakt door repeterende data (padding bytes).

Maar zelfs als ik slechts 8 random bytes toevoeg aan het password van elke tweakers account in de database en iedereen hetzelfde wachtwoord zou gebruiken, levert dat nog steeds allemaal unieke hashes op (bij de aanname dat de Tweakers database niet meer dan 10 miljoen users bevat).

Echter zonder de implementatie te zien, is het onmogelijk om te zeggen hoe lang de salt is welke een website toepast. Echter zijn er helaas maar weinig grote websites welke daadwerkelijk salts gebruiken van 64 bytes of groter (128+ tekens in hex) bij een user-based salt. Bij de systeem salt, gebruikt men wel vaker wat langere salts.

De beste methode is echter dat als de user- en systeem salt 64 bytes, voor de password hashing dan 128 byte salts te gebruiken, een combinatie van de systeem en user salt. Dit is erg belangrijk in het geval van een database dump (bijvoorbeeld een database backup welke minder goed was opgeslagen) dat dan niet direct alsnog alle wachtwoord op straat liggen..

Overigens ben ik inmiddels wel benieuwd wat het percentage websites is, welke hashes van meer dan 256 bits gebruiken (bijvoorbeeld SHA3-256), want men is steeds beter in staat collissions te vinden voor SHA1 hashes..

Overigens is het natuurlijk van de zotte dat de eigenaar op social media een wachtwoord gebruikt van slechts 6 alfabetische tekens. Ik hoop dat zijn user account binnen Facebook een veel sterker wachtwoord heeft, want het zou mij allerminst verbazen als hij geen total admin rechten heeft.

Beveiliging is zo sterk als de zwakste schakel. En dan kan de infrastructuur architect van Facebook nog zulke mooie security schemas opzetten. Maar deze zijn nog geen cent waard als Mark's interne password ook 'dadada' is...

+1

FreshMaker
@Royvs33 • 7 juni 2016 10:01

Nee, ze hebben hun eigen salt - daarvan is de berekening bekend jouw mail + ww + salt = XX1
De lijst van bv LinkedIn - mail + bekende ww + salt van Netflix = XX2 -> anders, dus veilig, zou de uitkomst XX1 zijn, onveilig -> ww aanpassen

Het is een stap extra, NF moet eerst de gegevens van de gehackte site krijgen, uitfilteren of er een overeenkomst is tussen hun gegevens ( mailadressen ) en de hacked list mailadressen.
De overeenkomsten door hun salt-maker

sturen voor de resultaten.

Het is een stap beveiliging die ik kan toejuichen, alleen is dan bekend of de gehackte lijst 'waar' is, en risico oplevert

+1

Standeman

@Toryu • 7 juni 2016 08:05

Dat blijkt

Netflix kan gewoon een hash maken met de salt die in hun database staat en deze hash vergelijken met die ze al hebben. Komen ze overeen, dan is hetzelfde wachtwoord gebruikt.

0 ouweklimgeit
@Standeman • 7 juni 2016 08:19

Een salt staat nooit in de database maar in configuratie bestanden. Anders zou een salt 0,0 toegevoegde waarde hebben wanneer iemand zich toegang weet te verschaffen tot de database

+2 Gomez12
@ouweklimgeit • 7 juni 2016 08:28

Yikes, een salt wil je juist wel in de database hebben en niet in de config, want je wil die laten verschillen per gebruiker.

Anders kan je met 1 gegenereerde tabel met 1 salt al je user-passwords achterhalen.
Terwijl als je hem in de dbase knalt je per gegenereerde tabel 1 user-account kan achterhalen.

0 Gomez12
@ouweklimgeit • 8 juni 2016 00:33

Why so difficult?

Het enige wat voor een user_salt relevant is is dat die apart is. Het genereren vanuit een "master salt" heeft totaal geen meerwaarde.

Je kan gewoon random wat getallen + letters genereren via een standaard random functie en je bent klaar...

+1

stverschoof
@ouweklimgeit • 7 juni 2016 08:33

Het is hier onder ook al gezegd, dus ik ga niet dieper in op dat je een salt wel per gebruiker in je db op wilt slaan, maar misschien wil je het volgende artikel wel lezen voor future reference over passwords en security https://nakedsecurity.sop...r-users-passwords-safely/

[Reactie gewijzigd door stverschoof op 7 juni 2016 08:33]

+1

Bacchus
@stverschoof • 7 juni 2016 09:22

Er is op zich wel iets voor te zeggen om de salt niet in dezelfde database als het gehashte wachtwoord op te slaan maar salt is in ieder geval uniek per wachtwoord. Je zou er voor kunnen kiezen een aparte salt-database te gebruiken of zelfs de salt gewoon weg te gooien.

+1

stverschoof
@Bacchus • 7 juni 2016 10:52

Er is op zich wel iets voor te zeggen om de salt niet in dezelfde database als het gehashte wachtwoord op te slaan maar salt is in ieder geval uniek per wachtwoord. Je zou er voor kunnen kiezen een aparte salt-database te gebruiken of zelfs de salt gewoon weg te gooien.

Een applicatie heeft alsnog toegang tot beide databases nodig want je hebt de salt nodig om te controleren of een ingevoerd wachtwoord + salt overeenkomt met het gehashde wachtwoord in de user database. Het hebben van verschillende databases heeft misschien wel wat voordelen, maar brengt ook een hoop kopzorgen met zich mee. Een salt weg gooien zoals je voorstelt lijkt me dan ook, onhandig.

[Reactie gewijzigd door stverschoof op 7 juni 2016 10:52]

+1 MachoSmurf
@ouweklimgeit • 7 juni 2016 08:30

Da's niet waar. Een salt wordt per gebruiker uniek gegenereerd en het boeit niet of een aanvaller deze in handen krijgt. Het doel van de salt is om te voorkomen dat een aanvaller met een Rainbow tabel in één klap de hele database kan controleren. Met de unieke salt per gebruiker moet elk wachtwoord opnieuw worden gecontroleerd tegen de gehele Rainbow tabel. Daarmee neemt de tijd benodigd voor een aanvaller extreem toe.

Dus nee, een salt vind je niet in configuratie bestanden. Al heb je wel gelijk in het feit dat het een aanval extra lastig maakt als je als aanvaller niet de beschikking hebt over de salts, maar dat is geen doel op zich.

+1 Ultra
@ouweklimgeit • 7 juni 2016 08:32

Nee, dat is een pepper: https://en.wikipedia.org/wiki/Pepper_%28cryptography%29

+1 mxcreep
@ouweklimgeit • 7 juni 2016 09:17

Het doel van de salt is niet meer en minder dan dat de hash bij hetzelfde wachtwoord toch verschillend is, daarnaast kun je meerdere hashing methoden combineren. Dat maakt de buitgemaakte hash uniek en dus niet traceerbaar via rainbow tables

[Reactie gewijzigd door mxcreep op 7 juni 2016 09:18]

0 ouweklimgeit
@Kain_niaK • 7 juni 2016 22:35

Lol? Een salt heeft niets met rainbow tables te maken, rainbow tables zijn voor wachtwoorden zonder salt zoals een simpele MD5 hash. Salt is juist bedoeld om rainbow tables tegen te gaan.

En theoretisch zou het wel kunnen, maar dan zou je een rainbow table moeten maken voor iedere mogelijke salt die bestaat.

0

Kain_niaK
@ouweklimgeit • 7 juni 2016 22:46

Salt is juist bedoeld om rainbow tables tegen te gaan.

Precies en dat is dus de hele functie van een salt. Zonder salt hoeft iemand maar één keer een rainbow table te genereren en kan dan door een volledige database van hashes gaan en meer dan 90% van alle passworden tot en met de maximale lengte die je hebt ingesteld bij het genereren van je rainbow table kraken (in de praktijk is dat 8 karakters, maar dat hangt van het gebruikte hashing algoritme af)

Bij het gebruik van een salt die per gebruiker en password uniek is kan dat niet meer. En een salt kan gewoon in de database staan en of de aanvaller de salt nu weet of niet maakt niet erg veel uit. Die salt maakt het password veel langer, en bij langere passworden is het gebruik van rainbow tables niet praktisch. Zo'n rainbow table zou veel te groot zijn en jaren duren om te generenen. Zelfs al weet je per gebruiker de salt ... je kunt die salts niet gebruiken om een rainbow table te maken en dan meerde passworden in één keer kraken. En dat is dus de hele functie van die salt. En uiteraard ook om dictionary attacks moeilijker te maken. Daar is de functie ook dat je niet zomaar meerdere passworden kunt vinden door één keer door de dictionary te gaan, door die salt heb je dan per gebruiker een dictionary nodig. Kortom het gebruik van een salt zorgt er voor dat een aanvaller niet meerdere hashes kan kraken in één poging maar per gebruikersnaam en password een poging moet doen. Om op die manier door een database heen te gaan duurt natuurlijk veel en veel langer.

[Reactie gewijzigd door Kain_niaK op 7 juni 2016 23:01]

+1 Toryu
@Standeman • 7 juni 2016 09:57

Misschien zie ik iets over het hoofd, maar wat Netflix hier doet, is eigenlijk gewoon een dictionary attack, en dat is precies waar goede encryptie algoritmes tegen beschermen.
Als ze inderdaad een unieke salt gebruiken, moeten ze voor elke user alle gelekte wachtwoorden hashen met de salt van die user. En dat proces dan herhalen voor elke user/salt. Het duurt honderden jaren om zo alle gebruikers te checken. Het kan dus bijna niet anders dat de salt niet uniek is.

Het staat eigenlijk ook gewoon in het artikel:
"Een groot deel van de uitgelekte wachtwoorden is al gekraakt en het bedrijf hoeft alleen maar een interne hash van het wachtwoord te creëren met een eigen algoritme."
Ze hoeven dus voor alle gebruikters slechts eenmalig de interne hash te creëren, niet voor elke gebruiker opnieuw. Dus, geen unieke salt.

[Reactie gewijzigd door Toryu op 7 juni 2016 10:03]

+1 aToMac
@Toryu • 7 juni 2016 08:06

Huh, wat is het verschil tussen een wachtwoord door je login code halen dat verkregen is door een gebruiker die het invoert of van een lijst verkregen door een hack?

+1 Durandal
@aToMac • 7 juni 2016 14:54

Niets, maar er is geen lijst die je wachtwoord bevat. Salt

+1 aToMac
@Durandal • 7 juni 2016 15:12

Ik weet wel wat een salt is hoor. Snap gewoon zijn logica niet dat ie hieruit concludeert dat ze geen salt hebben.

+1 Niemand_Anders

Beheer en beveiliging

@Toryu • 7 juni 2016 10:01

Netflix gebruikt wel een aparte salt per gebruiker. Echter een login gebeurt niet alleen op basis van een password. Je moet ook het email adres van de persoon hebben. Op basis van dat email adres kan Netflix jouw user record uit de database vissen, de user-salt toepassen met het buitgemaakte password en dan controleren of die hash overeenkomt met de hash in de database..

Als je het lastig vind om voor elke website een uniek wachtwoord te gebruiken en geen password manager wilt gebruiken, is er alsnog een eenvoudige methode het zelfs dan het hergebruik te beperken. Hackers gaan niet een-voor-een door zo'n buit gemaakte lijst. Daar maken zij een tooltje voor welke waarschijnlijk in een database correct credentials zal opslaan.

Op mijn mailserver maak ik gebruik van adres extensions. (in mijn geval .qmail-dmertens-default) op mijn domeinen. Alles wat ik achter 'dmertens-' plak wordt dan automatisch doorgezet naar het dmertens account. Op tweakers gebruik ik dus dmertens-tweakers@domein.nl, maar bij netflix is dit dmertens-netflix@domein.nl. Google Mail bied eenzelfde soort techniek aan, maar dan moet je plusje gebruiken, dus user+tweakers@gmail.com. Echter worden plus tekens eigenlijk nooit in emailadressen gebruikt. Streeptjes zien er wat natuurlijk uit..

Let op dat dit absoluut geen beveiliging is. Het is alleen een drempel welke het automatisch verifieren van credentials moeilijker maakt.

Een betere techniek als je slecht bent in het onthouden van je wachtwoorden, is eigenlijk alleen een basis wachtwoord onthouden zoals '!23Def' en daar de 'initialen' van de website achter plakken. Voor Tweakers zou je dan een wachtwoord kunnen krijgen zoals '!23DefT.n'..

Maar het gebruik van een goede password manager is eigenlijk de beste optie. Helaas kunnen niet alle websites goed omgaan met sterke wachtwoorden. Zo accepteert de KNAB bank geen vreemde tekens is het wachtwoord. Ook mocht het wachtwoord niet langer zijn dan 12 tekens. Ik hoop dat knab die beperkingen aan het wachtwoord inmiddels heeft opgelost, want ik heb de registratie niet voltooid omdat het bij dit soort beperkingen vrij zeker dat men het wachtwoord in plaintext opslaat. Da's namelijk de enige reden waarom je de lengte van een password zo kort zou maken. Echter al mijn wachtwoorden zijn minimaal 16 tekens lang en sinds midden 2015 staat mijn password manager op 20 tekens ingesteld..

Hoewel 2FA (Two factor Authentication) geen wondermiddel is, is het wel een goed middel om account theft te voorkomen als het wordt gebruikt in combinatie met andere security best practices..

0

Kain_niaK
@Niemand_Anders • 7 juni 2016 22:57

'!23Def' en daar de 'initialen' van de website achter plakken. Voor Tweakers zou je dan een wachtwoord kunnen krijgen zoals '!23DefT.n'..

Zo doe ik het. Ik heb een drie of vier tal basis sterke wachtwoorden en één zwak. Het zwak gebruik ik voor websites waar ik waarschijnlijk nooit meer op kom maar waar ik wel moet registeren (heb ik een kut hekel aan). En ook voor websites waar het me echt niks kan schelen als iemand op die account inlogt. De sterke wachtwoorden gebruik ik voor websites waar ik niet wil dat iemand er ooit op inlogt. Maar ik plak er altijd iets achter dat relevant is voor de website en dus zelfs als ik het vergeet dan kan ik het uitvogelen. En de 4 passworden gebruik ik al jaren en zal ik nooit vergeten. Lekt mijn hash uit dan is die hash dus anders voor elke website. Eigenlijk salt ik dus mijn eigen wachtwoorden.

0 fantafriday
@Toryu • 7 juni 2016 08:00

Je weet welke salt bij welke mail hoort. Voer het linkedin wachtwoord in bij het wachtwoord veld en als het jouw wachtwoord is kom je erin. Anders niet net als altijd...

+1 Nimja
7 juni 2016 07:49

Dit is een geweldig service. Bravo Netflix! De programmeur die dit heeft bedacht (en het was zeker geen marketing gast

) verdient een groot, koel biertje.

+1 GrooV
@Nimja • 7 juni 2016 08:00

Haveibeenpwned van Troy Hunt biedt dit al een tijdje aan als extra service voor website eigenaren, dit is dus niet echt speciaal maar wel de eerste grote site die het doet

+1

Ramon
@GrooV • 7 juni 2016 08:06

Volgens mij doet Microsoft dit ook al een tijdje.

+1

Gravit0n
7 juni 2016 11:20

Euh, horen wachtwoorden niet gehashed opgeslagen te zijn?
Ik vindt het nogal verontrustend dat iemand zomaar mijn wachtwoord kan inzien.

+1

DonJunior
@Gravit0n • 7 juni 2016 11:58

Je leest gewoon de reacties helemaal niet of?
Het is al meerdere keren genoemd namelijk dat ze de wachtwoorden die gevonden zijn in de diverse 'hacks' door hun eigen hash algoritme gooien en vervolgens de hash vergelijken met wat jij achter je account hebt staan aan gehashed wachtwoord.
Dus ja, de wachtwoorden horen gehashed opgeslagen te zijn.. en dat zijn ze ook.

0

koku
@DonJunior • 7 juni 2016 17:46

Hij heeft wel gedeeltelijk gelijk. Je hebt een plaintext wachtwoord nodig om die te kunnen hashen volgens je eigen algoritme. De wachtwoorden in de LinkedIn database zijn gehashed, maar zonder salt en met het verouderde sha1, dus de wachtwoorden in die database zijn met niet al te veel moeite te achterhalen. Dat is iets wat Netflix dus zal hebben gedaan. En daardoor weten ze in principe wat je LinkedIn wachtwoord was ten tijde van de hack. En indien deze overeenkomt met je Netflix wachtwoord (de gehashte versie) weten ze die ook.

Het is in mijn ogen een beetje een grijs gebied, maar uiteindelijk wel voor de verbetering van de veiligheid van gebruikers, als bedrijven zorgvuldig met die gegevens omgaan.

0 Frozenstorm
7 juni 2016 08:07

Nogal slecht dat dit mogelijk is, ook al heeft elke gebruiker hetzelfde wachtwoord ik zou het bij mijn applicaties niet kunnen raden/berekenen...

+1

InflatableMouse
@Frozenstorm • 7 juni 2016 08:28

Ik denk dat je het niet helemaal begrijpt.

[snip]

Ik begreep het blijkbaar zelf ook niet goed maar Gomez12 hieronder legt het wel goed uit.

[Reactie gewijzigd door InflatableMouse op 7 juni 2016 08:50]

+1 Frozenstorm
@InflatableMouse • 7 juni 2016 08:34

Ik doel op de volgende zin: "Een groot deel van de uitgelekte wachtwoorden is al gekraakt en het bedrijf hoeft alleen maar een interne hash van het wachtwoord te creëren met een eigen algoritme. De ontstane hash kan dan vergeleken worden met de eigen database."

Wat naar mijn idee is; kijken of hetzelfde wachtwoord bij ons is toegepast.

+1 NovapaX
@Frozenstorm • 7 juni 2016 08:54

Ja, dat klopt. Dat is niet anders dan wanneer je zelf in zou loggen.
Ze gebruiken de gelekte gebruikersnaam en het gelekte wachtwoord als invoer voor de authenticatie-code/functie, en deze wordt met de salt bij deze gebruikersnaam in hun database gehasht. Vervolgens wordt de verkregen hash vergeleken met de hash in de database.

Precies hoe normaal inloggen ook werkt dus....

[Reactie gewijzigd door NovapaX op 7 juni 2016 08:55]

+1 Gomez12
@Frozenstorm • 7 juni 2016 08:33

Dan weet ik niet wat voor kromme systemen jij hebt, maar in wezen zeg kan jij dus geen wachtwoorden verifiëren...

Wat hier gebeurt is dat er gewoon het clear-text password als dat bekend is door de password-routine wordt gegooid en als de hash gelijk is aan de opgeslagen hash dan wordt er een melding geproduceerd.

Ze gaan dus niet van hash->wachtwoord, maar gewoon van wachtwoord->hash en dan kijken of de hash gelijk is.

0 Frozenstorm
@Gomez12 • 7 juni 2016 09:38

En het wachtwoord (hashed) moet je dus ook niet kunnen vergelijken, zie het als die MD5 faal. Het kan prima dat ze het clear-text wachtwoord hebben en daarmee in proberen te loggen maar als je een hash kan vergelijken is dat zeker een punt van verbetering want je wil dat de uitkomst elke keer anders is. Sowieso de salt vastleggen moet je niet willen ookal is dat per gebruiker weer een andere.

+1 Gomez12
@Frozenstorm • 7 juni 2016 11:19

maar als je een hash kan vergelijken is dat zeker een punt van verbetering want je wil dat de uitkomst elke keer anders is.

Begrijp je wel wat je zegt?

Op de vraag : Mag deze user inloggen met dit password? Wil jij bewust dat de uitkomst elke keer anders is.
Schop dan gewoon je hele wachtwoord-routine eruit en doe het direct random dat is veel makkelijker.

0 Frozenstorm
@Gomez12 • 7 juni 2016 11:44

De hash moet elke keer anders zijn ook al wordt hetzelfde wachtwoord toegepast.

+1 hackerhater

@Frozenstorm • 7 juni 2016 13:29

De hash van een specifieke gebruiker met een specifieke salt zal altijd hetzelfde zijn. Het is niet mogelijk om anders de gegevens te controleren.

wachtwoord A + salt A => hash A
wachtwoord A + salt B => hash B
wachtwoord B + salt A => hash C
wachtwoord B + salt B => hash D

+1

DonJunior
@Frozenstorm • 7 juni 2016 10:14

"Het kan prima dat ze het clear-text wachtwoord hebben en daarmee in proberen te loggen "

"maar als je een hash kan vergelijken is dat zeker een punt van verbetering want je wil dat de uitkomst elke keer anders is"

Euh.. hoe ga jij dan inloggen met je clear-text password?
Je hasht je password field (bij het inloggen) om deze hash te vergelijken met de opgeslagen hash in de database toch? Dat is dezelfde vergelijking die je doet door zelf een hash te maken (met bijbehorend salt) van het wachtwoord en die te vergelijken met wat je in de database hebt staan.

0 Frozenstorm
@DonJunior • 7 juni 2016 11:32

Ik haal bij mijn uitleg dingen door elkaar; met clear-text bedoel ik te zeggen is dat ze de wachtwoorden gewoon door hun inlog protocol heen halen en kijken of het inloggen werkt (hash bevat het wachtwoord van de gelekte data). Met de hashed wachtwoorden bedoel ik dat deze output met die van de database vergelijken en is de salt static ipv dynamisch.

0 Durandal
@Frozenstorm • 7 juni 2016 14:56

En hoe wil je dan wachtwoorden kunnen controleren?

+1 Zer0
@Frozenstorm • 7 juni 2016 08:34

Ook bij jou applicaties kan het, simpelweg het wachtwoord van de gebruiker van de lijsten die gepubliceerd zijn proberen in je eigen applicatie, lukt het inloggen dat is het wachtwoord hetzelfde...
Automatiseer dit proces en klaar..

0 Frozenstorm
@Zer0 • 7 juni 2016 11:34

Dat klopt maar daar doel ik niet op, meer op het feit dat ze de nieuwe hash controleren met de hash van het huidige wachtwoord en hun salt dus static is.

[Reactie gewijzigd door Frozenstorm op 7 juni 2016 11:34]

+1 Zer0
@Frozenstorm • 7 juni 2016 13:02

En wie zegt dat ze een static salt hebben? Ik ben geen expert op het gebied van encryptie, maar of ze nu een static salt, dynamic salt, of voor mijn part peper en zout gebruiken, als gebruiker moet je met je gebruikersnaam en wachtwoord kunnen inloggen, en als een gebruiker met die gegevens in kan loggen kan een ieder met die gegevens inloggen, dus ook Netflix.
Er is ook geen sprake van raden of berekenen, er is sprake van testen. Er is een lijst met gebruikersnamen en wachtwoorden, en Netflix test of deze ook voor hun geldig zijn.

+1 hackerhater

@Frozenstorm • 7 juni 2016 13:31

Dat staat helemaal niet vast. De salt zal per gebruiker inderdaad niet veranderen (tot de wachtwoord vergeten optie wordt gebruikt) omdat je simpelweg dit nodig hebt om te kunnen inloggen!
Echt man lees eens hoe inlog systemen werken.

+1

Kalief
7 juni 2016 07:52

Op deze manier kunnen de hacks toch nog constructief worden ingezet.

+1 Twixie
7 juni 2016 08:49

Beetje off-topic, maar die password hack van Zuckerberg vind ik toch wel ongelooflijk anno 2016. Om te beginnen ongelooflijk dat een jonge CEO als Zuckerberg dergelijk belachelijk paswoord gekozen heeft. Zoiets verwacht je misschien van een 60+ CEO van traditionele bedrijven maar toch niet van de CEO van Facebook.
Daarnaast vind ik het wel heel bizar dat high profile sites als Twitter of Pinterest überhaupt toelaten dat gebruikers een paswoord kiezen dat bestaat uit TWEE unieke karakters en dan nog in een dergelijk repetitief patroon. De eerste de beste webshop heeft betere wachtwoordvereisten.

+1 yeroon17
7 juni 2016 09:05

Nette service van Netflix.
Hoewel het natuurlijk niet heel bijdehand is om overal hetzelfde wachtwoord te gebruiken...

+1 jeroeni22
7 juni 2016 10:04

Deze accounts worden voor een paar euro, zelfs eurocenten verkocht op the deep web.

Cookies op Tweakers

Netflix controleert of wachtwoorden gebruikers voorkomen in recente grote hacks

Lees meer

Nieuwste IT Banen

IT trainingen bij Computrain

Sorteer op:

Weergave:

Reacties (154)