SweKerhet - tråden om säkerhet

På mina två e-mail så var det endast ett som var exponerat, här ifrån Swec 2015.

Sen på dehashed skall man ha ett konto, så jag gick inte vidare...

En hel del dubletter, saker sträcker sig tillbaka till innan millennieskiftet, och det är inte bara mina konton men gattdejm

Vadå? Är inte "Logitech1" ett säkert lösenord?

Internetstiftelsens sida om säkerhet:
https://internetkunskap.se/sakerhet-pa-natet/

För att undvika missförstånd:

Nej, det stämmer inte. Skriv aldrig ut ditt eller någon annans lösenord i klartext någonstans

Ja, jag förstår att det var ett skämt

Tack för tråden, @medbor!

Jag hade inte hört talas om Dehashed, men tyckte tjänsten lät intressant. så jag tyckte det var värt ~80 SEK att se vilka av mina läckta lösenord (well, hashar) man knäckt. Och, jepp, det fanns faktiskt ett par träffar. För all del bara throwaway-konton med enkla ord + några siffor som lösenord, men ändå intressant att se.

I mitt fall var det läckta SweC-lösenordet bara md5-hashat (inte en saltad kombination av MD5 och SHA512, som det står).

INSERT INTO users (user, password) VALUES ('felplacrd', MD5('secret1234'));

Galet.

Antar att de skulle kunnat gå längre och sparat om lösenordet för alla som loggat in istf bara de som aktivt bytte lösenord?

Vet inte vilket "båda" som avses, men på t.ex. Sweclockers görs ju inget intressant med lösenordet på klientsidan alls, det skickas ju bara rakt av som ett formulärfält till servern.
Så menade mest att man även utan att byta lösenordet haft chansen att spara om det vid varje inloggning, då skulle ju fler användare vara i bättre skick vid varje given tidpunkt (fler sparade på rimligt sätt före varje ny potentiell läcka).

Att ha en sådan migrering permanent känns snarast önskvärt i mitt tycke, för det känns ju som att det alltid kommer dyka upp något nytt sätt att spara lösenord på som vore bättre, så länge man befattar sig med härket som är lösenord dvs... (HMAC-)SHA512 är ju inget bra sätt att spara lösenord heller t.ex.
(Typ sekvensen MD5, HMAC-MD5, HMAC-SHA512, PBKDF2 med 100000 iterationer, PBKDF2 med 200000 iterationer, ..., Argon2, ... osv kan ju en site som varit med ett tag ha hunnit gå igenom t.ex.)

Det jag menade var alltså i princip: vid inlogg validera lösenordet som vanligt, men håll även koll på om det sparade lösenordet var sparat enligt aktuell standard, om det inte är det och valideringen lyckats så spara om det

Trafiken i sig är krypterad iom. att HTTPS nyttjar TLS, alltså inte i klartext förrän terminerad på serversidan.

Och rent generellt så brukar man inte vilja hasha på klientsidan då autensieringen på serversidan förpassas till att jämföra den inkommande hashen med den i lösenordsdatabasen, hashen -blir- ditt lösenord. Ponera då att lösenordsdatabasen hamnar i orätta händer, ja då användarnamn+hash kan nyttjas för autensiering utan att man för den delen vet det underliggande lösenordet, så kan tredjepart logga på som vilken användare som helst. (Förutsatt att man inte kräver MFA)

Att hasha på klientsidan skyddar däremot lösenordet gentemot dåliga/felaktiga implementationer som t.ex. sparar lösenord i klartext.

För den som missat så finns CVE-2023-20198 med CVSS 10.0 i Cisco IOS XE som exploateras i det vilda.

IOC och exploitaktivitet finns beskrivet i artikeln nedan från Talos:
https://blog.talosintelligence.com/active-exploitation-of-cis...

@medbor Alla användares lösenord sparas om vid inloggning (om det behövs), så de använder den senaste standarden som är definierade av oss. Ökar vi t.ex. antalet iterationer så uppgraderas dessa användare automatiskt vid inloggning. De användare som inte loggat in på X tid och fått ett säkert lösenord har vi nollställt, vilket vi inte kommer att behöva göra för de användare som aktiverat 2FA.

Gårdagens siffror visade runt ~40k infekterade enheter.

Kör ni Cisco IOS XE med HTTP/S mgmt-interfacen nåbara på internet så plocka ner dessa omedelbart samt undersök IOC enl. artikeln ovan!

Hackare publicerar fejkannonser för lösenordstjänst..
https://omni.se/hackare-publicerar-fejkannonser-for-losenords...

https://blog.1password.com/okta-incident/
https://blog.1password.com/files/okta-incident/okta-incident-...

Om analysen stämmer så är det inte total panik, men det finns ju alltid en risk att de fått tag på något som indirekt ger mer åtkomst i ett efterföljande steg.

Bara för tydlighets skull om någon inte läser hela:

Addendum
Oct 21, 2023: Okta confirmed publicly that their internal support systems were compromised.
This answers how the HAR file was accessed by the attacker and that the initial compromise
was not through the employee’s laptop