Åpent brev til de som vedlikeholder nettbank.handelsbanken.no

Jeg er særdeles lite imponert over passordkravene til Handelsbankens nettbank.

Ved å hindre meg i å bruke “spesialtegn” så legger dere opp til at entropien i passordet blir langt mindre enn den kunne vært.

Jeg håper for guds skyld at dere salter og hasher passordene før dere lagrer dem. I så fall så skulle det jo ikke spille noen rolle hvilke eller hvor mange tegn jeg skriver
inn.

Den dagen dere blir hacket og passordbasen kommer på avveie, enten gjennom utro tjenere, spear fishing, en zero-day eller noe så gammelmodig og velprøvd som
sqlinjection så vil passordreglene deres gjøre brute-forcing av passordene MYE enklere for slemmingene.

Jada, jada, jada, jeg *vet* at dere har “strenge” sikkerhetsrutiner begrenser adgang til databasene og at
dere jevnlig har sikkerhets-auditing på alle systemer og at dere tar “brukernes sikkerhet på alvor”,

Tror dere kanskje ikke at LinkedIn, Dropbox, EHarmony og de andre sitene som ble hacket bare i år *ikke* tok “brukernes sikkerhet på alvor”?

Hvis du går inn på https://www.grc.com/haystack.htm så kan du se at hva forskjellen på å tillate spesialtegn gjør ift
hvor lett det er å brute-force passord hvis man sitter på både saltet og hashen, for dere lagrer vel gjerne disse to rett ved siden av hverandre i samme databaserad også?

Et eksempel på et passord som i utgangspunktet ser veldig sikkert ut er QrY8Tv9w1 en rask sjekk på tidligere nevnte side avslører at kompleksiteten på å knekke dette passordet ligger
på i området halvannen dag (dog gitt en *veldig* kraftig maskin). Hvis dere hadde tillatt “spesialtegn” kunne jeg endret det til QrY8Tv9w! (ser du utropstegnet på slutten)?
dette øker kompleksiteten til to og en halv måned.

Problemet med å være restriktiv på hvilke tegn brukere får legge inn er at dere gjør det MYE lettere for slemminger å teste stjålne passordhasher og derfor gjør dere det MYE mer
attraktivt for de samme slemmingene å få tak i dataene. Man kan nesten si at dere maler en stor målskive på nettbanken deres, slår dere på brystet
og roper til verden “BARE KOM HER OG PRØV DERE, VI ER TILSYNELATENDE IKKE SÅ GOD PÅ DETTE MED SIKKERHET”. Og jeg må være helt ærlig når jeg sier at jeg er litt ubekvem med å ha pengene mine
stående i en bank som utbasunerer dette til alle sine kunder hver gang de skal skifte passord.

Nå er jo dette selvfølgelig ikke et problem dersom ingen slemminger noensinne finner ut at dere begrenser passordentropi for sluttbrukerne deres.

Vi får håpe at ingen av dem leser dette da.

 

——-

Har du sett, Handelsbanken svarte meg samme dag som jeg henvendte meg til dem. Her følger epost-dialogen:

Fra Handelsbanken:

Hei igjen, og takk for innspill 

Sikkerheten rundt vår nettbank og våre databaser diskuteres kun internt. 
Så du får ikke noe svar på dine spørsmål/antagelser. 

Men som du vet, så holder det ikke bare med passord ved innlogging i nettbanken. 
Innloggingen krever et vite-element (passord) og et ha-element (kodebrikke). 
For deg som kunde betyr det at du må ta kontakt med vår sperretjeneste – hvis noen av disse to 
mistenkes å være på avveie. 

I de hackede tjenestene/sidene du viser til, slik som LinkedIn, Dropbox, EHarmony etc. besto sikkerheten ved innlogging 
kun av et vite-element, ha-elementet var fraværende. 

Nå var det vel de færreste av de 6,5 millioner  berørte LinkedIn-brukerne som fikk LinkedIn-profilen sin vandalisert på grunn av innbruddet. Problemet er at folk gjenbruker passord på tvers av tjenester…

Jeg prøver med en ny mer oppklarende epost til Handelsbanken:

Hei igjen, takk for raskt svar, 

 

Det gjelder ikke bare innlogging til nettbanken som sådan, den dagen databasen kommer på avveie så vil den være relativt lettere hackbar, 

dvs at passord i basen relativt lettere blir hacket, dvs at alle de kundene som bruker samme passord (f.eks min mor og hennes syklubb) overalt da vil være mer sårbare fordi hackerne lærte passordene å kjenne gjennom deres system.

 

Alle de andre stedene bruker ikke fler-faktor-autentisering så potensielt setter dere døren på gløtt for “slemmingene” mange steder på internett, selv om dere selv er beskyttet gjennom kodebrikker.

 

Mitt poeng er primært at dersom dere hasher passord så *spiller det ingen rolle* hva input er. ALLE moderne algoritmer kan operere på ALLE karakterer man kan fremprodusere på et keyboard.

 

Den eneste grunnen til å sette begrensninger i brukernes passord er dersom man ønsker å kunne opplyse kunden om passord f.eks per telefon, men jeg velger å tro at dere ikke er så langt unna gode praksiser at dere faktisk muliggjør dette for deres kundebehandlere.

 

et annet tankemoment er at dere “tvinger” brukeren inn i dårligere passordvaner.

 

Det eneste positive jeg kan tenke meg med regelsettet deres er at siden så mange andre *krever* spesialtegn, at dere i så måte “tvinger” brukeren til å ha et unikt passord for handelsbanken i stedet for å gjenbruke et som han allerede bruker på facebook.

 

Men å gjøre policyen (passord isolert sett) sin til den minst sikre på internett er en underfundig måte å oppnå slik sikkerhet på.

 

jeg benytter LastPass til mine passord og ønsker aller helst å få den til å generere sikre unike passord til meg. Handelsbankens passordregime gjør det vanskelig for meg å følge best practice som sluttbruker. 

 

Hvordan kan da deres praksis være et eksempel på en god praksis?

Igjen imponerte Handelsbanken med å svare lynraskt, dog ble jeg ikke særlig mye klokere på om mitt innspill falt for døve ører:

Hei 

Som jeg nevnte i forrige mail, sikkerheten rundt våre systemer diskuteres kun internt. 

Ihht banken policy så har jeg heller ikke anledning til å komme med kommentarer 
utover de du fikk i mitt første svar. 

—- Takk skarru ha!

Advertisements

Brilliant Chunking of IEnumerables

I recently needed to chunk a *huge* IEnumerable into manageable chunks (SqlServer only allows _so_ many parameters in a single query (update x where y in *huge ienumerable*) )

So I came across this little gem on StackOverflow: http://stackoverflow.com/questions/1349491/how-can-i-split-an-ienumerablestring-into-groups-of-ienumerablestring/3935352#9136291

    public static class IEnumerableExtension
    {
        public static IEnumerable<IEnumerable> Chunks(this IEnumerable source, int chunkSize)
        {
            var chunk = new List(chunkSize);
            foreach (var x in source)
            {
                chunk.Add(x);
                if (chunk.Count < chunkSize)
                {
                    continue;
                }
                yield return chunk;
                chunk = new List(chunkSize);
            }
            if (chunk.Any())
            {
                yield return chunk;
            }
        }
    }

ASPNET_COMPILER: “Circular file references are not allowed” or “how bad neighbors can ruin the neighborhood”

Yesterday I came across a cute little bug in our codebase (asp.net) which had me totally stumped for a bit.

After a massive change in an underlying API which introduced breakage left and right I had finally managed to get the codebase to compile again and was about to investigate whether changes were needed in the code-front files (.ascx / .aspx / .master). In order to do this somewhat efficiently I ran the aspnet_compiler.exe on the codebase to see what it would tell me:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler -p “E:\*path_to_solution*\*project_directory*\” -v “E:\temp\compilationoutput”

It barfed on me exclaiming “Circular file references are not allowed”. Well isn’t that just nice? I’m fairly certain that I don’t have any “circular file reference”s in the codebase so just what does this mean? After googling a bit I tried running a modified command:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler -p “E:\*path_to_solution*\*project_directory*\” -v “E:\temp\compilationoutput” -fixednames e:\temp\aspnetout

which ran without any such errors.

 

after thinking for a bit I realized what the problem was: Asp.Net compiles all ascx-controls *in the same folder* into *one* dll. So if you have two folders A and B, each with two controls (A1, A2 and B1,B2), while it is obviously not good to have A1 reference B1 and B1 reference A1 back, it is not so obviously similarly no good having A1 reference B1 and also B2 reference A2. Even though none of the files have a circular references, because of the way they are packaged into dlls the resulting dlls *do* have circular references.

There are two ways to fix this:

1) compile each control into its own dll. That way they are not affected by their “neighbors'” behaviors at all (this is done by the aspnet_compiler when you specify “-fixednames”, it is also achieved in the running code by setting batch=”false” in the compilation section of web.config)

2) compile *all* controls into a single dll (however, afaik there is no way to specify this, neither using aspnet_compiler or using web.config)

 

In the end I tracked down which control was being a lousy neighbor to the other controls in the same folder and moved it to a new neighborhood