I början av 2000-talet fanns siten ”Interface Hall of Shame”. Denna site visar exempel på värdelösa grafiska användargränsnitt. Min favorit är hur de relaterar till någon som på ett forum undrade hur en dropdown meny kunde fås att fungera när man hade tusentals möjliga val i den. Svaret är: varför vill du ens bygga något så dumt?

Säkerheten är inget undantag från att dålig design. Eller, vad som nästan är ännu värre, exempel på egenpåfunna lösningar. Som jag skrivit i tidigare blogginlägg: inom säkerhetsområdet är det i stort sätt alltid en dålig idé att komma på sin egen krypteringsalgoritm och tro att den kommer förbli säker om man bara låter bli att berätta hur den fungerar.

Men det finns många tillfällen där personer och företag har byggt lösningar utan att förstå säkerheten bakom.

I Windows 95 sparades lösenorden man loggade in med i ett format som Microsoft själva hade hittat på. Hur det fungerade höll man givetvis för sig själva. Och det tog inte lång tid för några duktiga hackare att knäcka det. Lärdomen av det, som jag skrev ovan, är att inte hålla det hemligt och att inte försöka bygga algoritmerna själv.

Säkerhetsexperten Steve Gibson kom på en metod för att skydda datorer från överbelastningsattacker. Innan hans lösning blev ens byggd, tittade några andra säkerhetsexperter igenom vad han gjorde reklam för och sågade lösningen. Den var inte säker. Steve hade inte pratat med någon annan medan han satt på kammaren och byggde vad han trodde var en perfekt lösning. Dessutom hade han troligen inte koll på att en liknande lösning redan fanns och hade används under ett antal år. Lärdom: prata med andra om din lösning och kolla om du måste bygga den överhuvudtaget.

De som uppfann den trådlösa krypteringsmetoden WEP gjorde en katastrofalt dålig lösning som visade sig var extremt enkel att knäcka. Om man skyddar sitt trådlösa nätverk med WEP, är det i princip som att skicka data i klartext. Anledningen till problemet var att man inte förstått hur man krypterar säkert och gjort några nybörjarfel i designen. Lärdomen är att se till att man förstå området man ger sig in på innan man bygger sin lösning. Bara för att du själv inte kan hacka din egen lösning, betyder det inte att andra inte kan.

Och jag har själv gjort en tavla. Jag byggde ett autentiseringssytem i php som jag var mycket noggrann med att säkra. Alla inmatningar kontrollerades och sanerades. Databasanropen skedde med ett nedlåst konto. När jag provade att göra en SQL-injektion, lyckades jag hacka min egen lösning på första försöket Jag hade helt enkelt glömt att kontrollera datat från inmatningsfältet för lösenordet, vilket är det andra fältet som skickar data till applikationen. Lärdomen är att inte anta du gjort allting rätt för att du tycker att du kan området. En förmildrande omständighet var att jag faktiskt kollade säkerheten innan jag släppte applikationen lös på nätet.

Säkerhetsområdet kan vara svårt att förstå och jag tror att det korrekta sättet att hantera det är att vara öppen och låta andra titta på vad du gör. Se till att källkoden till det du bygger släpps fritt på nätet om du kan. Använd alltid testade och vedertagna principer när du arbetar med säkerhet. Försök inte göra allt själv och förlita dig inte helt och hållet på någon enstaka person som har rykte om sig att vara en guru.