Kommunens epost­kontoer brukt til massiv spam­posting. Ny konto kapret i dag [Ekstra]

[Harald Brombach (digi.no)]

Kommunens epost­kontoer brukt til massiv spam­posting. Ny konto kapret i dag [Ekstra]

[Gjest Slettet-t8fn5F]

Er det bruk av emioys som gjør at overskriften ser så tåpelig ut?

 

[sedsberg]

Er det bruk av emioys som gjør at overskriften ser så tåpelig ut?

 

Nei, det er pga. inkompetanse. Redaksjonen vet ikke hvordan de skal klare å få til visse tegn.

[Gavekort]

Nei, det er pga. inkompetanse. Redaksjonen vet ikke hvordan de skal klare å få til visse tegn.

 

Det er nok ikke redaksjonen sin feil, men en teknisk feil i oversetting HTML-kodede tegn. Vi er klar over dette problemet.

[sedsberg]

Det har uansett vært slik lenge, og det tolker jeg som at de (hvem enn som er ansvarlig) ikke klarer å fikse problemet. Redaksjonen var nok feil ord ja.

[Ximalas]

Det er forundelig at vi fortsatt kaller det for passord og ikke kaller det for passfrase. Det blir ikke bedre når Active Directory ikke lar oss finjustere passordkravene utenom minimum og maksimum lengde, unikhet blant de N siste passordene, gyldighetsperiode, og hvorvidt passordene må være «komplekse». Azure AD har av en eller annen grunn satt maksimal lengde til 16 tegn. Det er på høy tid å forlange bedre styring av passordregler i systemene som anskaffes. Er minimum lengde på 10 tegn og minst ett (eller to?) ordmellomrom en god start?

[Kakeshoma]

Lengdegrensen i 365 er veldig merkelig ja, men kan omgås om man bruker AAD Connect fra lokal AD.

 

Ellers finnes det 3.partsløsninger for finjustering av passord. Enig i at dette burde vært mulig i AD ut av boksen.

[Gjest Slettet-t8fn5F]

Det er forundelig at vi fortsatt kaller det for passord og ikke kaller det for passfrase. Det blir ikke bedre når Active Directory ikke lar oss finjustere passordkravene utenom minimum og maksimum lengde, unikhet blant de N siste passordene, gyldighetsperiode, og hvorvidt passordene må være «komplekse». Azure AD har av en eller annen grunn satt maksimal lengde til 16 tegn. Det er på høy tid å forlange bedre styring av passordregler i systemene som anskaffes. Er minimum lengde på 10 tegn og minst ett (eller to?) ordmellomrom en god start?

Her er innstillingene til passord i AD og som er felles for hele domenet. Hva er det du savner?

 

[Kakeshoma]

Det han savner er nok feks det å kunne nekte passord som er i vanlige rainbow tables, nekte bruken av passord hvor du bare endrer et tall på slutten osv..

Dette er blant mulighetene du har i SpecOps Password Policy.

[Ximalas]

 

Det er forundelig at vi fortsatt kaller det for passord og ikke kaller det for passfrase. Det blir ikke bedre når Active Directory ikke lar oss finjustere passordkravene utenom minimum og maksimum lengde, unikhet blant de N siste passordene, gyldighetsperiode, og hvorvidt passordene må være «komplekse». Azure AD har av en eller annen grunn satt maksimal lengde til 16 tegn. Det er på høy tid å forlange bedre styring av passordregler i systemene som anskaffes. Er minimum lengde på 10 tegn og minst ett (eller to?) ordmellomrom en god start?

Her er innstillingene til passord i AD og som er felles for hele domenet. Hva er det du savner?

 

Du har fortsatt ingen mulighet til å finjustere «kompleksitetskravene». De er hardkoda. NetIQ eDirectory og Identity Manager har bedre muligheter til å detaljstyre passord/-frasenes oppbygning.

[Gjest Slettet-t8fn5F]

Du har fortsatt ingen mulighet til å finjustere «kompleksitetskravene». De er hardkoda. NetIQ eDirectory og Identity Manager har bedre muligheter til å detaljstyre passord/-frasenes oppbygning.

Nei heldigvis kan man bare slå av eller på det kravet. Slår man det på, er kravet at passordet har 3 av 4 komponenter i seg. Stor / Liten bokstav. Spesialtegn og tall. Tre av de må være med. 

Noe mer komplekse passord enn det, medfører at folk skriver opp passordene og lagrer de på gule lapper på skjermen eller i nærheten, noe som medfører at sikkerheten senkes på systemet.

[Gjest Slettet-t8fn5F]

[qualbeen]

Ingen andre som reagerer på at de har analysert alle passord, for å se hva som er mest brukte? 

 

Dette må* jo bety at alle passord er tilgjengelig i klartekst. Klartekst! I 2019! Hvor mange tusen brukere var det kommunene hadde? Alt fra skolebarn til politikere til ansatte ... Du trenger ikke være redd for hackere, holder med én utro IT-ansatt (eller konsulent), og vipps så er alle passordene lekket. Gøy!

 

*Rent teoretisk kan passordene være hashet, for så å bruke kjente rainbow-tables for å hente ut passordet. Men det fungerer jo bare dersom de hasher passordene uten salt. Og da er man like langt; passordene er i praksis som ren tekst å regne ... 

 

Dersom passordene er både saltet og hashet, ville det krevd alt for mye regnekraft til at de hadde giddet å regne ut hva som er mest brukte passord. Så passordene kan umulig være saltet og hashet! Full strykkarakter til kommunen!

 

(Og delvis stryk til kommentarfeltet; hvorfor har ingen andre løftet denne bekymringen? For jeg er da vel ikke helt på bærtur?!)

[-Night-]

Ingen andre som reagerer på at de har analysert alle passord, for å se hva som er mest brukte? 

 

Dette må* jo bety at alle passord er tilgjengelig i klartekst. Klartekst! I 2019! Hvor mange tusen brukere var det kommunene hadde? Alt fra skolebarn til politikere til ansatte ... Du trenger ikke være redd for hackere, holder med én utro IT-ansatt (eller konsulent), og vipps så er alle passordene lekket. Gøy!

 

*Rent teoretisk kan passordene være hashet, for så å bruke kjente rainbow-tables for å hente ut passordet. Men det fungerer jo bare dersom de hasher passordene uten salt. Og da er man like langt; passordene er i praksis som ren tekst å regne ... 

 

Dersom passordene er både saltet og hashet, ville det krevd alt for mye regnekraft til at de hadde giddet å regne ut hva som er mest brukte passord. Så passordene kan umulig være saltet og hashet! Full strykkarakter til kommunen!

 

(Og delvis stryk til kommentarfeltet; hvorfor har ingen andre løftet denne bekymringen? For jeg er da vel ikke helt på bærtur?!)

 

 

Err nei, du kan ta en dump av alle passord hasher for og finne hvilke hasher som er gjengangere. dette er vantlig innenfor pentesting og sikkerhet testing.   Ja det er fult mulig og legge på noe jern for at disse skal knekkes men krever ganske mye jern før at det skal komme gjennom. 

 

https://www.dionach.com/blog/active-directory-password-auditing

 

Jeg gjør selv dette når jeg tar AD revisjon og etter avtale med ledelser vil jeg prøver og dekryptere de passordene som er mest brukt, typiske steder for dette er gjort er på tjenestebrukere. 

 

 

de fleste burde uansatt see på Azure AD med funksjoner som de har innebygget som gjør bedre sikkerhet samt siden norske kommuner skal være mindre enn et normal hage i andre land så må de sentralisere IT drift til fylke, eller enda større at blir en felles AD infrastruktur på tvers av Kommune Norge slik som DSS gjør (nesten) for statlige 

 

https://www.microsoft.com/en-us/microsoft-365/blog/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks/

Endret 13. mars 2019 av -Night-