Een beetje domme gebruikers. Om bij TripAdvisor in te kunnen loggen, moeten ze toch ook zelf de wachtwoorden of de hash ervan opgeslagen hebben. Hoe denken die gebruikers dan dat TripAdvisor controleert of het inlogwachtwoord klopt?

Als de hash met salt uniek per site zou zijn dan is enkel door reverse hashing het originele wachtwoord te achterhalen.
Het zegt dat de hash ofwel reversable is wat heel fout is of dat de salt niet uniek is en vele sites de zelfde salt gebruiken. Dat is het hergebruik van een password zoals admin:admin hetgeen ook fout is..

Best er over nagedacht dat er iets niet klopt I.p.v. Zo maar een bewering te geloven.

Of dat Tripadvisor de in het artikel genoemde collectie elders gelekte wachtwoorden met de in hun eigen wachtwoorddatabase vastgelegde salts heeft gecombineerd en gehasht en gekeken heeft of de zo berekende hash gelijk is aan de vastgelegde.
Nadenken helpt inderdaad.

Ook bij een unieke salt per wachtwoord, zal TA deze salt (moeten) weten!
Anders kunnen ze namelijk je originele wachtwoord niet controleren.

Er is helemaal geen reden om het originele wachtwoord te achterhalen. Je pakt gewoon de gelekte wachtwoorden en hashed dat met je eigen unieke salt. En vervolgens vergelijk je het resultaat met je eigen database van hashes.

Dat is ook hoe inloggen doorgaans werkt. De gebruiker tikt het WW in, vervolgens wordt het, al dan niet lokaal, gehashed en die hash wordt met de opgeslagen hash vergeleken.

Je hebt gelijk zo staat het ook in het artikel.
Dat betekent dat ze de massale gelekte ww's zonder enige afscherming er tegen aan gehouden hebben.
Voor een review met tekst ergens lijkt me dat een overkill niet proportioneel. Dan liever de kwaliteit van reviews.

Waarom zou dat zonder enige afscherming gebeurd moeten zijn?

Als je verscillende hashes net andere salts gebruikt zijn de hashes zelf niet vergelijkbaar. Al de salt bekend is kun je met een plain text user wachtwoord naar dezelfde hash komen.

Als je niet wachtwoorden in plain text op slaat zul je die alsnog moeten vergelijken door de omzetting te haken.

Laat je wachtwoorden in plain text binnenkomen dan heb je iets anders wag niet goed zit.

Wat ik me afvraag is of Tripadvisor ook de nieuwe wachtwoorden gemaild heeft.

Op het moment dat zij constareren dat iemand passwords op straat liggen mogen ze ook aannemen dat mogelijk de email van de klant gecompromitteerd is. In dat geval zitten ze wachtwoorden naar de criminelen te sturen ... wel zo makkelijk

Eh, ja, maar waarom zou het vergelijken van een verzameling wachtwoorden die elders gelekt zijn met de salts en hashes die TripAdvisor voor hun eigen users heeft vastgelegd zonder enige afscherming moeten gebeuren? Men kan echt wel beschikken over de salts en hashes die men zelf heeft vastgelegd. Het combineren van de gelekte wachtwoorden met de eigen salts vergt CPU/GPU-tijd maar kan prima in in een afgeschermde omgeving gedaan worden. Waar slaat "zonder enige afscherming" op? Ik snap niet waaruit je afleidt dat afscherming ontbroken moet hebben.

‘Hash en salt” geeft al aan dat deze commentaren worden verstrekt door ict profs. Succes in jullie nieuwe wereld , maar ik ben de weg kwijt. Kan er ook nog iemand iets uitleggen in “ ICT voor dummies”. Ik heb de opleiding niet gehad, maar vind het knap hoe snel jullie mee gaan in deze ontwikkeling.

Je gaat met leesbare klantgegevens plain text voor de koppeling aan de slag. Inkoop doorgeven etc
Je gaat met de daaraan gekoppelde plain text wachtwoorden aan de slag en noemt dat niet veilig?

Alles wat je daar gebruikt heeft Iers met plak text direct herleidbaar. De aanname ik doe het zelf met een usb stick en Excel en ik maak geen fouten is nu net de bron van fouten.
Daarbij het is iets wat een keuze van de gebruiker is. Hij kan altijd zijn ww met een ieder delen.

Als TripAdvisor random salt gebruikt (wat waarschijnlijk is), dan hebben ze een hele klus gehad om hun database te checken. Iedere gebruiker heeft dan zijn eigen salt (opgeslagen in de gebruikersdatabase). Dus de checking procedure is dan als volgt:
gegeven een plain text wachtwoord met rangnummer i, lees de salt van gebruiker met rangnummer j, hash het gegeven wachtwoord i tezamen met de salt van gebruiker j en kijk of het resultaat hetzelfde is als de hash die opgeslagen is in de gebruikersdatabase van TripAdvisor. Indien hetzelfde: signaleer probleem, anders ga door. Dit is dus een geneste loop over i = 1 t/m aantal gelekte wachtwoorden en over j = 1 t/m aantal TripAdvisor gebruikers.

En jij praat altijd over zo hoog over security? Blijkbaar mis je toch iets.

Sorry...... Maar je snapt duidelijk de gedachte er niet achter.

Het is juist een uitstekende actie, die ook andere bedrijven al eens gedaan hebben. Dit is gewoon goed en veilig uitvoeren in een omgeving.

Wat heeft trouwens inkoop hier nu weer mee te maken?

Men gaat met inlognaam (e-mailadres) + salt + hash aan de slag. Wat heeft dat met inkoop te maken? Dit is een tabel die ze sowieso hebben en die kan via beveiligde verbindingen die ze ook sowieso hebben worden overgezet naar een goed beveiligd systeem en na de verwerking daar weer worden verwijderd.
Als men dit niet op een veilige manier kan doen dan ontbreken de basisvaardigheden die ze nodig hebben om hun systemen te kunnen beheren.
Ik heb geen idee wat "Iers met plak text" betekent. En wat is er direct herleidbaar? Men heeft een rekenintensief proces dat een verzameling wachtwoorden met een verzameling salts+hashes vergelijkt en daar hoeft alleen maar uit te komen bij welke inlognaam een match is gevonden, niet welk wachtwoord het precies was. Je neemt kennelijk aan dat dat wel is vastgelegd maar dat blijkt nergens uit.

De lijst met gevonden inlognamen wordt vervolgens gebruikt om wachtwoorden te resetten en de betrokkenen in te lichten. De kopie van de data waarmee men gewerkt heeft kan vervolgens vernietigd worden. Zodra de wachtwoorden van de gevonden gebruikers gereset zijn kan de lijst met plaintext-wachtwoorden trouwens niet eens meer misbruikt worden om deze user-accounts te compromitteren.
Je doet dus de aanname dat het met een USB-stick en Excel is afgehandeld (naast de al behandelde aannames) en daar baseer je een conclusie op. Dan is de "conclusie" zelf een aanname, heb je dat niet door? Garbage in, garbage out.

Voor alle duidelijkheid: ik claim niet dat ze het op een goed beveiligde manier hebben uitgevoerd, maar wel dat dat voor een professionele IT-organisatie prima te doen is. Als het zowel op een goede als op een slechte manier uitgevoerd kan zijn is er zonder nadere informatie geen basis om te concluderen hoe het werkelijk gedaan is. Jij trok wel een conclusie en ik vroeg naar de basis daarvoor, en je kwam met niet meer dan uit de lucht gegrepen aannames, niet met iets dat zelfs maar begint te overtuigen.