Taggat med: nist

NISTs uppdaterade riktlinjer för lösenord

NIST Password Lösenords policy

Det amerikanska organisationen National Institute of Standards and Technology (NIST) uppmanar till att överge gamla metoder för lösenord till förmån för mer nya och effektiva skydd. Här har jag sammanfattat sex viktiga insikter från NIST:s nya rekommendationer som kan hjälpa Er organisation att skapa moderna och säkra lösenordspolicyer:

1. Prioritera längden på lösenordet framför komplexitet

Tidigare har många organisationer krävt komplexa lösenord med stora och små bokstäver, siffror och specialtecken. Men ny forskning visar att människor ofta skapar förutsägbara mönster som gör lösenorden lättare att gissa.

NIST föreslår istället att fokusera på lösenordets längd. Uppmuntra därför användare att skapa långa lösenfraser, som kombinerar orelaterade ord, exempelvis “lamas-kasett-trumpet7”. Dessa är både enklare att komma ihåg och svårare att knäcka än komplexa men förutsägbara lösenord.

2. Möjliggör långa lösenord

NIST rekommenderar att stödja lösenord upp till 64 tecken för att ge maximal flexibilitet och säkerhet. Även om lösenfraser inte är osårbara, erbjuder de bättre skydd än kortare alternativ. Se till att dina system tillåter tillräckligt långa lösenord:

SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.

3. Inför multifaktorautentisering (MFA)

Enligt undersökningar från Microsoft saknade 99 % av alla komprometterade konton MFA. NIST understryker att MFA inte längre är valfritt – det är ett måste. Kombinera lösenord med ytterligare autentiseringsfaktorer för att öka säkerheten ytterligare.

4. Undvik frekventa lösenordsbyten

Många användare ogillar att ofta behöva byta lösenord ofta, och NIST rekommenderar att slopa denna praxis om det inte finns bevis för att ett lösenord har komprometterats. Ofta leder sådana krav till svagare lösenord, då användarna gör minimala ändringar. En mer balanserad strategi är att förlänga tiden mellan byten och istället använda verktyg som upptäcker komprometterade lösenord såsom HaveIBeenPwned.

5. Blockera komprometterade lösenord

Att använda lösenord som redan finns i databaser över tidigare läckor är en stor säkerhetsrisk. NIST rekommenderar att man kontrollerar nya lösenord mot dessa databaser för att förhindra att komprometterade lösenord används igen. Detta kan eliminera en vanlig attackmetod innan den utnyttjas. Och för att implementera detta kan exempelvis k-anonymitet användas eller nedladdade databaser från HaveIBeenPwned.

6. Sluta med lösenordstips och säkerhetsfrågor

Traditionella metoder som lösenordstips och säkerhetsfrågor är föråldrade och bör ej användas. Med dagens tillgång till information via sociala medier är svaren ofta enkla att hitta. NIST föreslår istället att använda säkrare alternativ som återställningslänkar via e-post eller MFA vid lösenordsåterställningar.

Att anpassa sig till NIST:s riktlinjer är ett viktigt steg mot starkare lösenordssäkerhet i din organisation. Genom att fokusera på lösenordslängd, använda MFA och förebygga vanliga misstag kan du skapa en säkerhetspolicy som är både användarvänlig och robust.

Här kan du läsa hela det nya dokumentet med rekommendationer:

Kali Purple från OffSec

Kali Purple

Förutom att Offensive Security numera går under namnet OffSec så har företaget även släppt en ny version av Kali Linux som heter Kali Purple.

Som det nya namnet lite avslöjar så handlar det om en Linux-distribution som är anpassad för Purple-Teaming eller Blue-Teaming, dvs mer defensiv cybersäkerhet än offensiv som Kali Linux är mest känt för.

Och givetvis så är Kali Purple proppad med över 100 st olika verktyg, och för att nämna några:

  • Arkime full packet capture (tidigare Moloch)
  • Cyberchef
  • Elasticsearch SIEM
  • GVM vulnerability scanner
  • TheHive incident response platform
  • Malcolm
  • Suricata IDS
  • Zeek IDS

Även så följer alla andra verktyg som vi är bekanta med från Kali Linux med också.

Menystrukturen följer NIST CSF:

  1. Identify
  2. Protect
  3. Detect
  4. Respond
  5. Recover

Med följer även Kali Autopilot som låter dig bygga olika attackscenarion samt en community Wiki som låter dig läsa på om olika defensiva verktyg och hur du använder dessa.

Skärmdumpar

Kali Autopilot

Kali Autopilot

SOC-in-a-box

Kali Purple Soc in a box

Reddit hackade

Reddit som är en av världens största webbsajter (plats 6 enligt Alexa) har hackats. Intrånget genomfördes via tvåfaktors-återställningskoder som skickas ut via SMS. Denna typ av tillvägagångssätt blir vanligare och vanligare vilket har fått NIST att ej längre rekommendera just 2FA-återställning via SMS, vilket jag skrev om 2016.

Antagonisten som hackade Reddit kom åt nya E-postadresser, gällande en sammanfattning som skickades ut. Samt en databas med användarnamn och lösenord från 2007.

Om du använder Reddit och har samma användarnamn och lösenord sedan 2007 så kommer Reddit att varna dig. Jag tycker dock att Reddit ändå bör skicka ut en varning till samtliga användare eftersom lösenord kan användas på flera sajter.

Reddit har även anställt en Head of Security samt söker personal till flertalet befattningar såsom:

Mer info hos Reddit i /announcements.

Nya lösenordsrekommendationer från NIST: Ju längre desto bättre

Den amerikanska myndigheten NIST släppte nyligen uppdaterade rekommendationer gällande hantering av lösenord. Dessa uppdaterade rekommendationer kommer precis lagom till det att SVT Dold uppdagat att massor av läckta lösenord och användaruppgifter finns på nätet att tanka ner. Många av dessa läckta lösenord är så klart hashade eller krypterade som i fallet med Adobe (läs här hur du knäcker lösenord).

Dessa nya rekommendationer från NIST innehåller bl.a. att användare ska ges möjlighet att välja lösenord upp till 64 tecken. Även ska lösenord tillåtas att innehålla specialtecken såsom unicode, space och emojis.

En annan bra sak är att rekommendationerna från NIST anser att du bör kontrollera de lösenord som användaren anger mot listor med vanligt förekommande lösenord. Samt så bör du ta bort password hints och Knowledge-based authentication (KBA) såsom frågor ”din moders ogifta efternamn”, ”din förstfödde hunds bästa kompis”.

Minst 32 bitar slumpad salt ska användas samt en hashfunktion godkänd av NIST såsom PBKDF2 och med minst 10,000 iterationer.

Dokumentet innehåller även en hel del andra vettiga saker såsom att SMS för 2FA inte bör användas (troligtvis pga SS7 attacker och nummerportabilitet mellan operatörer).

Avsnitt 2 av SVT Dold kan du se här: www.svtplay.se/video/11171365/dold/dold-sasong-2-avsnitt-2

Uppdatering: SVT har av någon anledning tagit bort avsnittet.

OpenSSH 6.2

openssh

Nyss så släpptes det en ny version av OpenSSH. Denna nya version innehåller en rad förbättringar såsom MAC över krypterade paketet istället för klartext:

Added support for encrypt-then-mac (EtM) MAC modes for SSH protocol 2. These modes alter the packet format and compute the MAC over the packet length and encrypted packet rather than over the plaintext data. These modes are considered more secure and are used by default when available.

Även så har OpenSSH implementerat stöd för GCM-AES:

GCM (Galios/Counter Mode) is a mode of operation that uses a universal hash function over a binary Galois field to provide authenticated encryption. The mode is defined in NIST’s SP 800-38D, and P1619. GCM is a high performance mode which offers both pipelining and parallelization

Se changelog här: openssh.com/txt/release-6.2

SHA3 Säkerhetsbuggar

Företaget Fortify som är specialicerade på att hitta sårbarheter i mjukvaror. De har nu gjort en rapport på de hashkanidater som är kvar i den amerikanska tävlingen SHA3. Resultatet blev enligt följande:

The National Institutes of Standards and Technology (“NIST”) is holding a competition to choose a design for the Secure Hash Algorithm version 3 (“SHA-3”). The reference implementations of some of the contestants have bugs in them that could cause crashes, performance problems or security problems if they are used in their current state. Based on our bug reports, some of those bugs have already been fixed.

Läs rapporten i sin helhet här: blog.fortify.com/repo/Fortify-SHA-3-Report.pdf

Fortify har även en trevlig blogg: blog.fortify.com/blog/fortify/