Intrång hos Foodora – 25 000 svenska konton påverkas

Utan att ha ett unikt salt per användare så förlorar man en stor del av vinsten med det dock. Det är också bättre att generera ett slumpmässigt salt än att köra med datum eller liknande och om man väl saltar ser jag ingen poäng med att göra saker svagare i onödan.

Bcrypt är fortfarande säker med rätt parametrar vad jag. Att algoritmen är gammal är ganska ointressant om den väl gör det den ska.

Jag förstår, men jag tycker att det är viktigt att påpeka att folk bör använda algortimer som är ämnade för hashning av lösenord, inte de vanliga snabba algoritmerna som används för andra ändamål. Sedan behöver man kanske inte gå in på exakt vilka.

Som pekades på i artikeln så kan man ofta sälja uppgifterna, reklambolag tar gärna listor med mail-adresser.

Det är säkert OK. Mest jag som blir misstänksam att någon har knäckt den för länge sen och spionerar med hjälp av det, som av allt att döma hände med NSA och RC4.

Frågan jag svarade på från början frågade om olika typer, så då nämnde jag några av de vanligaste. Sen kunde jag ju i sammanhanget tänkt på att ta några som används till lösenord, men jag får vill skylla på semesterhjärna.

https://www.hd.se/2020-06-09/kopte-langos-via-natet-blev-av-m...

Verkar som Foodora hanterat det hela väldigt dåligt.

Så fort man läste databas från 2016 förstod man det var en kopia som användes i test-system, ett ofog som är alldeles för vanligt på för många företag, istället för att lägga ner en veckas jobb på att skapa script att populera test-databaser så tar man en kopia av produktionssystem och "sparar" några mantimmar.

Håller med fullständigt.
Som jag skrev ovan, ofta ren lathet och dumsnålhet som företag tar kopior på sina databaser och använder i testmiljöer, är ju oftast relativt enkelt att skriva ihop scripts för att skapa upp dummy-data.
Men det finns lite knepiga fall där man behöver testa på skarp data för att hitta de där ovanliga buggarna men då måste man säkra upp test-miljön i samma grad som produktion vilket återigen inte händer p.g.a. av lathet, tidspress och dumsnåla beslut på företagen.

Inget nytt, detta har begått sen urminnes tider med kopior av skarp data i test men det har blivit värre av flera anledningar de senaste 20 åren i takt med system anslutna till Internet, rapid deployment, continues delivery, devops där allt ska uppdateras hela tiden och alla ska lägga ut ny mjukvara och alla är överarbetade så man funderar inte ens på vad man gör utan kör med skygglappar på och allt runtomkring är hinner man inte ta hänsyn till. Hoppades naivt att GDPR skulle stävja detta men ser inte att det haft någon effekt.

Eftersom detta är en databas från 2016 och använts i en testmiljö så är båda argumenten ej tillämpliga.
Att det ska finnas transaktionshistorik för revision av verksamheter, verifiera skatter, löntagare, kunder mm är en bra sak, går visserligen att diskutera tidsramen men överlag handlar det om att skydda konsumenter och staten mot oseriösa verksamheter.

Ja, som jag skrev innan, finns väldigt få fall där skarp data behövs i testsystem och när det verkligen behövs så måste systemen hanteras lika säkert som de skarpa systemen.
Sen vet jag inte om man ska skylla allt på lata programmerare, finns förmodligen ett mångfald av programmerare som gärna skulle ta sig tiden att skriva verktyg för att generera relevant dummy-data eller anonymisera den skarpa datan men den saken hamnar längst ner i varje sprint när sprint master får direktiv från product manager som får krav från customer solution director som får krav från..... (kedjan kan bli lång i vissa verksamheter).... company board, aktieägare.

Är bakom betalvägg.
Vet inte om det är tillåtet på sweclockers.com att kopiera artiklar men jag kan inte tänka mig att det är det så istället för att kopiera texten från artikeln så kanske du kan sammanfatta den i ett par meningar med egna ord så vi får reda på vad den gäller?

Ange gärna en källa på att kunden hålls ansvarig utan möjlighet till ersättning för att man har 2FA via SMS.

Det där med att alla företag utan kollektivavtal skulle vara onda är väl något sånt där som vissa tror blir sant om dom bara upprepar det nog många gånger. Det blir det inte.

Jag har vid ett par tillfällen tidigare försökt maila direkt till Foodoras utvecklare (efter att ha blivit helt ignorerad på deras Facebook) för att påpeka de mest uppenbara bristerna i deras tjänst, t.ex. bristerna i deras Android-app. Aldrig fått en tillstymmelse till svar.

Skitföretag

Om nu företaget har bättre villkor än kollektivavtalet så är det väl bara att skriva på, avtalet reglerar minimumnivå?
Ett kollektivavtal skyddar dessutom din lön, om inbetalningar till FORA skiter sig etc.
En del säger att man håller sig utanför kollektivavtal men betalar samma summa för de anställda, vilket ofta är sant men det man inte nämner är att procenten som den anställde får ta del utav är mindre. Alltså samma summa för arbetsgivaren men mindre i fickan för den anställde vid pension.
Utan ett kollektivavtal så är minimilönen 0:- vilket innebär att arbetsgivaren kan förändra både din lön och livssituation inom en väldigt kort period.

Men om man har kredit så har du ju alltid "pengar på kortet" så att säga.

Eller snåla kunder som inte vill betala programmerarens tid med att fixa en testmiljö.

Man kan ju tycka att det vid det här laget skulle kunna finnas helt fiktiva kunduppgifter i en gigantisk fri-att-använda-databas, redo att tankas, just för såna ändamål.

Slutade använda betalkort på nätet, sedan det visade sig att jag varit i London och Paris samma kväll och tydligen köpt en massa Escort-tjänster.

På nätet finns att ladda ner s.k. "rainbow tables", där man har tagit alla de vanligaste lösenorden och kört igenom några av de vanligaste hashnings-algoritmerna. Istället för att köra hashnings-algoritmen, kan man bara jämföra alla resultat från de läckta lösenorden med dessa tabeller. Hittar man en matchning har man knäckt lösenordet.

Om hela databasen har ett fixerat, känt salt så måste man först få reda på det (kanske inte så svårt, har man ett enda läckt lösenord så kan man använda det till att räkna ut saltet) och sedan ändå ta hela den där "ordlistan" med vanliga lösenord och köra den igenom algoritmen en gång. Många lösenord tar lång tid att köra, så i praktiken tvingas man nöja sig med färre lösenord att testa mot.

Har man gjort rätt och haft unika salt, måste man alltså köra hela den där ordlistan en gång för varje användare för att åstadkomma samma sak. Det tar ännu längre tid.

Min poäng var att även om man använt en bra hashnings-algortim, så är det kört för ganska många kunder om man inte har saltat den, eftersom det finns massiva rainbow tables att ladda ner.

https://stripe.com/docs/payments/3d-secure

Se stycket "Disputed payments and liability shift". Om 3D secure (dvs Verified by Visa och Mastercard SecureCode, metoden de använder när de skall ha 2FA över SMS - du ser det blinka förbi i browsern lite snabbt) har använts, är det din bank som blir betalningsskyldig och inte affären du köper ifrån. Det betraktas alltså på samma sätt som om någon har stulit kreditkortet. Detta gör att det skall hanteras av ARN. ARN är extremt villig att bedöma ett beteende med kreditkort som grovt oaktsamt:

https://www.konsumenternas.se/betala/olika-betalformer/om-kon...

Alltså hamnar det på hur någon kommer över den där 2FA-koden. Någon kan ha stulit, eller bara lånat, din telefon - SMSen syns ju på låsskärmen utan att man låser upp den. Jag speglar normalt sett mina SMS till paddan och till den ena datorn, så man kan använda någon av dessa för att kringgå 2FA om man får tag i dem. Se texten ovan - om någon har stulit ditt kreditkort ur en låst bil, så är det ditt problem, för du har varit grovt oaktsam. Med samma logik är det ditt problem om någon kommer över din telefon eller annan kopplad enhet. Har extremt svårt att tro att ARN skulle ställa sig på konsumentens sida i ett sådant här fall.

Jag ser ingenting här som stödjer det generella påståendet om att kunden skulle vara utan möjlighet till ersättning om SMS används för 2FA. Grov oaktsamhet lär gälla oavsett metod för 2FA, t.ex. om du har ditt BankID på oskyddade enheter och berättat för andra vad du har för PIN kod till dina BankID osv.

Varför skulle man inte få radera data beroende på GDPR?