Etikettarkiv: Internet

Bra RFC om identifiering

Kommunicerande system använder och utbyter ständigt olika typer av identifieringsinformation. Exempel på identifieringsinformation är värdnamn, IP-adresser, e-postadresser och resurspekare (Eng: Uniform Resource Identifier – URI).

Men om kommunicerande parter tolkar identifieringsinformationen på olika sätt och hanterar informationen på olika sätt kan problem uppstå. Typiskt kan en legitim användare av en resurs nekas tillgång till resursen. Eller omvänt att en användare (som inte behöver vara en människa) får tillgång till resurser denne inte skall ha tillgång till.

IETF har publicerat en informations-RFC som på ett mycket bra sätt går igenom vilka problem som kan uppkomma vid användning av olika typer av identifieringsinformation. Om du arbetar med att bygga system som på något sätt använder identifieringsinformation är RFC 6943 – Issues in Identifier Comparison for Security Purposes väl värd att läsa igenom. Det är lätt att göra enkla misstag vilka ofta får säkerhetsmässiga konsekvenser. Eller som dokumentet så snyggt sammanfattar det hela:

Screen Shot 2013-06-19 at 09.47.04

451 – Ny felkod vid censur

Tim Bray, skaparen av XML numera anställd på Google har skrivit ett förslag om att utöka listan för felkoder i HTTP med en ny kod. Den nya koden, med föreslagna numret 451 ska användas för att meddela användare att den utpekade resursen inte går att nå på grund av legala skäl.

I draft-tbray-http-legally-restricted-status skriver Tim:

This document specifies an additional Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied for legal reasons. This allows server operators to operate with greater transparency in circumstances where issues of law or public policy affect their operation. This transparency may be beneficial both to these operators and to end users.

Koden 451 är, naturligtvis inte slumpmässigt vald, utan anspelar på nyligen bortgångne Ray Bradburys bok Farenheit 451.

Kostnaden för att knäcka CAPTCHAs

För en vecka sedan skrev jag om Pensionsmyndighetens beslut att införa en teknisk lösning kallad CAPTCHA för att stoppa robothandel. Det jag försökte visa var att det problem myndigheten sade sig ha inte är en bra lösning – en CAPTCHA stoppar inte datorer, samtidigt som den valda lösningen försvårar för mänskliga användare och slår ut bra tjänster.

reCAPTCHA
reCAPTCHA

En metod för att forcera CAPTCHAs myndigheten öppnar upp sig för som jag beskrev är att använda människor som stödfunktion för datorer. Jag fick efter min postning frågor om hur realistiskt det är  – om det går att göra och om det inte kostar för mycket. Som tur postade Boingboing en artikel om tjänster där människor används för att attackera CAPTCHAs. Och där finns det bra prisinformation. Artikeln handlar om ett ryskt företag, KolotiBablo som kopplar samman arbetare med applikationer som behöver knäcka CAPTCHAs:

Paying clients interface with the service at antigate.com, a site hosted on the same server as kolotibablo.com. Antigate charges clients 70 cents to $1 for each batch of 1,000 CAPTCHAs solved, with the price influenced heavily by volume. KolotiBablo says employees can expect to earn between $0.35 to $1 for every thousand CAPTCHAs they solve.

Dvs maximalt en tusendels dollar för en CAPTCHA. KolotiBablo är lång ifrån den enda tjänsten. Tjänsten med det vackra namnet Deathbycaptcha tar 1.39 USD för 1000 CAPTCHAS och redovisar dessutom lite statistik för sin tjänst. Medeltiden att knäcka en CAPTCHA är 17 sekunder och har 90% chans att lyckas.

För den som vill läsa mer om KolotiBablo finns mer i en artikel om företaget och dess tjänster hos KrebsonSecurity (en artikel som Boingboing pekar på). Det finns även en bra forskningsartikel som tittar närmare på ekonomin för att knäcka CAPTCHAs, en artikel väl värd att läsa om du vill förstå hur denna marknad fungerar.

Säkerhetsfunktioner i Javascript

Javascript har utvecklats från att vara ett enkelt scriptspråk som körs i en webbläsare till att bli ett populärt språk som även används på servrarsidan, i desktopapplikationer och i inbyggda system. Javascript i sig är ett mer kapabelt språk än man kanske tror, och dessutom utvecklas mycket, spännande funktioner till Javascript. Bland annat inom säkerhetsområdet.

Techworld och Slashdot berättar att tyska företaget Recurity Labs har utvecklat en implementation av OpenPGP (RFC 4880) i Javascript. Implementationen, GPG4Browsers är i dag implementerad som en plugin till Google Chrome. Med GPG4Browsers går det bland annat att kryptera, dekryptera och signera, verifiera epost samt importera och exportera certifikat direkt i webbläsaren. GPG4Browsers stödjer de symmetriska kryptona AES, CAST5, DES, Blowfish och Twofish, hashfunktionerna SHA (från SHA-1 tom SHA-512), MD5 och RIPEMD-160. Slutligen stöds även de asymmetriska funktionerna RSA, DSA och El Gamal.

Även om GPG4Bwosers i dag är en plugin finns källkoden tillgänglig. När jag tar en titt på kryptofunktionerna ser jag inga uppenbara beroenden till Chrome, utan det ser ut att vara ren, väkommenterad och troligen portabel kod. För att vara kryptokod är den faktiskt ovanligt väl strukturerad och kommenterad. Ser dock inte ut att vara optimerad för prestanda (mycket loopar och funktionsanrop). Koden är öppen kod enligt LGPL.

Ett annat bibliotek som ger kryptfunktioner i Javascript är Stanford Javascript Crypto Library (SJCL). Detta bibliotek är byggt för att vara litet (kodmässigt och RAM-mässigt), vara enkelt att använda samt använda vettiga grundinställningar. De funktioner som tillhandahålls är AES, SHA-256 samt några olika kryptomoder (CTR, CCM, OCB2). Dessutom finns lösenordsfumktionen PBKDF2. Det skall även finnas en experimentell version som implementerar de asymmetriska funktionerna ECDH och ECDSA. SJCL är licensierad antingen under BSD eller GPLv2. Det finns en testsida för att se att en port av SJCL fungerar. Så här såg det ut när jag testade:

Test av SJCL. Notera prestasiffrorna
Test av SJCL. Notera prestasiffrorna

Den sista länken jag vill peka på är en sida som diskuterar slumptalsgeneratorer i Javascript. Den generator som finns i Javascript (definierad i ECMA-262) är inte den speciellt bra. Den duger speciellt inte i säkerhetsfunktioner. Sidan ovan beskriver de tekniska skälen till kvaliteten hos standardgeneratorn samt presenterar en samling med olika slumptalsgeneratorer med bättre egenskaper. Notera att vi i det här läget pratar om pseudoslumptalsgeneratorer (PRNG). Använder du slumptal mycket i dina Javascript-applikationer kan detta vara en sida värd att lägga en stund på. Den kod som finns är BSD-licensierad.

MQTT – ett nytt protokoll för Internet of Things

Förra veckan meddelade IBM att dom skulle donera ett nytt protokoll till Eclipse Foundation. Protokollet MQTT  (MQ Telemetry Transport) är ett transportprotokoll avsett för meddelanden till och från små Internetkopplade enheter (Internet of Things – IoT).

Vad gäller framtidens Internet tror många – Ericsson, Cisco inte minst att antalet uppkopplade enheter kommer att öka drastiskt, och domineras av saker runt omkring oss. Glödlampor, kylskåp, hissar, dörrar, tvättmaskiner och bilar är bara några exempel på prylar som nämns som tänkbara IoT-saker.

Ericssons vision om Internet of Things-utvecklingen
Ericssons vision om Internet of Things-utvecklingen

Men för att detta ska gå att genomföra måste den intelligens som behöver byggas in i alla dessa prylar vara så kompakt och billig att det inte tillför kostnader. Kostnader såväl vid inköp som användning. Detta ställer stora krav på den tekniska implementationen i alla dess delar för att bli så billig, liten och energisnål som möjligt. Det som krävs är väsentligen:

  • Någon slags strömkälla. I vissa fall kan detta ske genom extern matning. Ett bra exempel är passiva RDID-brickor där avläsaren tillför den ström som krävs. Det pågår även mycket forskning om energy harvesting, vilket innebär olika tekniker att fånga in energi från omgivningen – exempelvis från ljus, rörelser, temperaturskillnader.
  • En kommunikationskanal – oftast en radio, men även enklare trådbunden kommunikation.
  • Eventuella sensorer – om det är så att prylen ska kunna rapportera sitt tillstånd, inte bara en identitet. Tänk en glödlampa där man troligen vill kunna veta inte bara vilken glödlampa det är, utan om den lyser eller inte. Eller om den är trasig.
  • En digital intelligens. Väsentligen en liten processor som implementerar de protokoll, kommandon och funktioner som krävs för att rapportera status, skicka larm ta emot förfrågningar och kommandon som krävs för att göra prylen till en IoT-pryl.
Det MQTT försöker göra är att förenkla kommunikationsprotokollen för att utbyta meddelanden.
MQTT är inte helt nytt. Två tidigare protokoll, SCADA protocol och MQ Integrator SCADA Device Protocol (MQIsdp) är samma sak som MQTT.
Säkerhetsmässigt innehåller MQTT stöd för att skicka lösenord(!). Men för att sökra sessionen föreslår MQTT-teamet att använda SSL.
I samband med donationen bildar Eclipse en arbetsgrupp runt M2M och pressreleasen beskriver syftet med arbetsgruppen närmare.
The Eclipse Machine-to-Machine Industry Working Group and the related open source projects will enable customers to integrate physical world systems into their enterprise solutions,” said Dr. Angel Diaz, vice president, software standards, IBM Software Group. “Data is being captured today as never before, the Eclipse M2M initiative helps expand the spectrum of information and intelligence into the systems and processes that make the world work and become a smarter planet.”
För den som vill veta mer om MQTT finns det massor att läsa, både på MQTT.org. Bland annat finns specifikationen för version 1.3 av MQTT-protokollet (fast specen ligger faktiskt hos IBM). Specifikationen listar några egenskaper med MQTT:
  • The publish/subscribe message pattern to provide one-to-many message distribution and decoupling of applications
  • A messaging transport that is agnostic to the content of the payload
  • The use of TCP/IP to provide basic network connectivity
  • Three qualities of service for message delivery:
    • ”At most once”, where messages are delivered according to the best efforts of the underlying TCP/IP network. Message loss or duplication can occur. This level could be used, for example, with ambient sensor data where it does not matter if an individual reading is lost as the next one will be published soon after.
    • ”At least once”, where messages are assured to arrive but duplicates may occur.
    • ”Exactly once”, where message are assured to arrive exactly once. This level could be used, for example, with billing systems where duplicate or lost messages could lead to incorrect charges being applied.
  • A small transport overhead (the fixed-length header is just 2 bytes), and protocol exchanges minimised to reduce network traffic
  • A mechanism to notify interested parties to an abnormal disconnection of a client using the Last Will and Testament feature
Jag vet inte riktigt hur jag ska ställa mig till MQTT. Att det kommer fram protokoll som gör det enklare (billigare) att implementera maskin-maskin-kommunikation (M2M) och IoT är bra. Det behövs definitvt och protokoll och säkerhetesmekanismer behöver anpassas för att möta de hårda kostnads- och enkelhetskrav dessa prylar ställer.Men jag svårt att se vad som fundamentalt förändras med MQTT. Vad gäller själva säkerheten lämnar protokollet över detta till SSL (och TLS – förhoppningsvis). Men dessa säkerhetsprotokoll är i sig så komplexa och dyra att implementera att kostnaden för transport- och meddelande-protokollet blir marginell.
Vidare blir jag tveksam till varför IBM väljer att donera MQTT till Eclipse Foundation. Eclipse Foundation gör en massa vädligt bra saker och har iaf ett projekt riktat mot M2M (Koneki). Men deras huvudfokus är knappast Internet of Things, och inte heller kommunikationsprotokoll. Varför donerades detta inte till IETF, W3C eller en ren SCADA- eller , M2M-organisation?
Uppdaterad 2011-11-14
Som Jonas påpekar nedan används MQTT av Facebook som del av deras meddelandetjänst. Lucy Zhang, utvecklare på Facebook beskriver deras erfarenhet av MQTT:
One of the problems we experienced was long latency when sending a message. The method we were using to send was reliable but slow, and there were limitations on how much we could improve it. With just a few weeks until launch, we ended up building a new mechanism that maintains a persistent connection to our servers. To do this without killing battery life, we used a protocol called MQTT that we had experimented with in Beluga.
MQTT is specifically designed for applications like sending telemetry data to and from space probes, so it is designed to use bandwidth and batteries sparingly. By maintaining an MQTT connection and routing messages through our chat pipeline, we were able to often achieve phone-to-phone delivery in the hundreds of milliseconds, rather than multiple seconds.

STEED – Initiativ för kryptering mellan ändpunkter

Sprang på ett nytt säkerhetsinitiativ kallat STEED. Tanken med STEED är att utveckla kryptering som spänner hela vägen mellan ändpunkterna i en kommunikation och skall vara så enkel att använda att det alltid (ofta) används. Initiativtagarna till STEED skriver:

End-to-end e-mail encryption is still ignored by almost all users. The mails are left in the clear in the mailboxes of the web mail providers, where they are frequently collected by attackers and lead to an escalation of the attack due to the sensitivity of the mail content. We suggest a new and simplified infrastructure to protect mail that is compatible with OpenPGP and S/MIME and relies on an easy-to-use trust model without a central administration.

Initiativtagarna är i det här fallet Marcus Brinkmann och Werner Koch från Tyska företaget g10CODE, kanske mest kända för att driva utvecklingen av GnuPG.

Det SPEED är tänkt att erbjuda är saker som:

  • Automatisk nyckelgenerering
  • Automatisk nyckeldistribution
  • Opportunistisk kryptering
Tillsammans är detta egenskaper avsedda att göra säkehetsanvändningen så osynlig som möjligt som användaren. I första hand verkar STEED vara fokuserat på mailtjänster. Det finns en artikel av Marcus och Werner som närmare beskriver vad de vill åstadkomma med STEED och hur detta är tänkt att ske. Vi får se om STEED flyger eller inte, men initiativ som gör säkerhet enklare att använda och därmed mer utbredd gillar jag.

Verified by VISA och kapprustning inom IT-säkerhet

Ett blogginlägg hos Optinet satte fingret på den kapprustning och utveckling av offensiva kontra defensiva metoder inom IT-säkerhet. (Ja, jag är medveten om att det inte bara gäller IT-säkerhet, utan generellt. Folk anpassar sig till förutsättningarna och försöker hitta nya metoder och vägar att nå sina mål.)

Som ett sätt att öka säkerheten vid kortbetalningar på Internet har VISA och sedan andra kreditkortsbolag infört ett system kallat 3-D Secure. Systemet bygger på att kopla tre domäner till varandra (därav namnet 3-D) – Domänen för mottagaren av betalningen, domänen för utbetalande institut och domänen för den som tillhandahåller transaktionen. De olika kortföretagen har sedan lanserat systemet under olika namn, ex Verified by VISA eller MasterCard SecureCode.

För dig som användare  märks systemet genom att du hamnar på en sida som ser ut ungefär så här (om du använder VISA):

Verified by VISA
Verified by VISA

Som användare får du mata in ett lösenord för att transaktionen skall accepteras. Lösenordet har du tidigare varit tvungen att registerera hos din kortutgivare – din bank eller liknande.

Säkerheten hos kreditkorten byggde från början på enbart kreditkortsnummer och namnet till kortinnehavaren samt viss sidoinformation som datum.  Nästa steg var att införa säkerhetskoder som inte är inpräglade i kortet och oftast ej heller finns lagrat i magnetremsan (kallas Card Security Code eller CVV). Men fortfarande är informationen som behövs för att verifiera en transaktion tillgänglig för den som kommer över informationen på det fysiska kortet. Det är bland annat detta Secure-3D ändrar på (så vida du inte har lösenordet skrivet på kortet).

Bedrägerierna mot kort har också utvecklats (och drivit fram de nya metoderna). Från början plockades kortnummer och information från prägligen genom att samla in karbonpapper och kvitton. När detta försvårades genom koderna på baksidan dök skimming upp och har blivit allt mer avancerad. I dag är korten ofta utrustade med inbyggda chip som tillsammans med PIN-kod ska höja säkerheten lokalt och skydda mot skimming. Tyvärr är protokollet som används i Chip+PIN trasigt, vilket öppnar för lokala bedrägerier med stulna kort.

Blogginlägget Verify by VISA-bedrägeri visar att skurkarna är i full gång med att försöka gå runt även Secure-3D-skyddet. I det här fallet handlar det om rent phishing via mail:

Phising mot Verified by VISA
Phising mot Verified by VISA

Texten ovan är vad som skickats ut till användare i mail. Man försöker uppebarligen får det att se ut att komma från kortföretagen och vill få dig att lämna ut lösenordet. Kallas för Phising, eller när det är riktat direkt mot en enskild måltavla Spear Phising.

För att denna attack ska lyckas krävs naturligtvis att skurkarna även har kortnummer, namn, utgångsdatum och Card Security Cocde. Men det hindrar dom inte från att försöka. Och även om dom inte själva har kortinformationen är ett lösenord i sig värt pengar på den svarta marknaden.

Bloggpostningen är värd att läs och har många bra tips. Jag vill dock upprepa det viktigaste av dom:

Din bank eller kreditkortsleverantör kommer aldrig under några som helst omständigheter att via mail fråga om ditt lösenord eller be dig att nollställa det. De kommer inte heller att fråga om ditt kortnummer. Detta är det enda man behöver komma ihåg för att inte bli lurad i denna typ av bedrägeri.

Som användare blir det allt fler moment och information som ska tillhandahållas. Men än så länge finns det (så vitt jag vet) ingen ny teknisk lösning som ger både högre säkerhet och enklare användning för denna typ av transaktioner.

Faran med lagmässigt framtvingade bakdörrar

Bruce Schneier har postat en bra essä om faran med lagmässigt framtvingade bakdörrar.

Vad det handlar om är att myndigheter av olika skäl kräver att det ska skapas tekniska sätt att komma åt kommunikation och data hos operatörer och privata aktörer. Detta brukar kallas legal intercept eller lawful intercerption, men även sveriges FRA-lag och datalagringsdirektivet kan sägas vara exempel på detta – även om de tekniska formerna skiljer. Gemensamt för dessa funktioner är att de skapar en separat väg in i systemen, en bakdörr.

Så vad är problemet med en separat ingång för myndigheter, förutom de rent politisk och moraliska aspekter man kan ha? Jo problemet är att bakdörren löper risk att missbrukas – både av myndigheterna själva (syftesglidning eller personal som går utanför sina befogenheter), men även av andra som inte alls rätt att använda bakdörren, men öppnar och kliver på ändå. Det Bruce visar i sin essä är att denna typ ab missbruk inte alls är teoretiska. Bruce skriver:

Google made headlines when it went public with the fact that Chinese hackers had penetrated some of its services, such as Gmail, in a politically motivated attempt at intelligence gathering. The news here isn’t that Chinese hackers engage in these activities or that their attempts are technically sophisticated — we knew that already — it’s that the U.S. government inadvertently aided the hackers.
In order to comply with government search warrants on user data, Google created a backdoor access system into Gmail accounts. This feature is what the Chinese hackers exploited to gain access.

Bruce krönika är inte ny (från januari 2010), men jag tycker den fortfarande är väldigt läsvärd och relevant.

Cookie-RFCn 6265

Daniel Stenberg har skrivit en bra postning om den nya RFC, RFC 6265 – HTTP State Management Mechanism som dokumenterar Cookies.

Det är rätt märkligt att en mekanism på Internet som är så otroligt vanlig inte varit ordentligt specificerad. Min uppfattning är att denna brist på specifikation och dokumentation är ett skäl till att cookies varit en källa till sårbarheter och säkerhetsproblem. Förhoppningsvis leder den nya RFCn till att det går att städa upp implementationer. Och inte minst att RFCn blir ett avstamp för vidareutveckling.

Frankrike förbjuder nog inte hashade lösenord

Det har varit en hel del diskussioner på bland annat Twitter om att Frankrike sägs ha förbjudit hashade lösenord, att det nu krävs att lösenord lagras i klartext. Diskussionerna startade med postningen ”France Outlaws Hashed PasswordsSlashdot. I postningen pekas det på en artikel hos BBC om hur nätföretag som Google motsätter sig den nya lagen.

Som många andra tänkte jag att vad är nu detta för galenskaper. Men när jag läser artikeln i fråga blir jag tveksam. BBCs artikel innehåller inte speciellt mycket detaljer, men det som står där är:

The law obliges a range of e-commerce sites, video and music services and webmail providers to keep a host of data on customers.

This includes users’ full names, postal addresses, telephone numbers and passwords. The data must be handed over to the authorities if demanded.

Om man sedan gräver lite i diskussionerna på Slashdot dyker det upp att det verkar röra sig om ett dekret från 2004. Och nu kan jag inte franska, men ska man tro de på Slashdot som säger sig kunna det står det inget om förbud att hasha lösenord, eller att de måste lagras i klartext.

När vi pratar om hashade lösenord handlar det om att man i ett system inte sparar själva lösenordet, utan bara den signatur man får genom att köra den genom en kryptografisk hashfunktion. Det som lagras i systemet är signaturen, inte lösenordet. När ett lösenord ska verifieras tas användarens inmatade lösenord emot, detta körs genom hashfunktionen och sedan jämförs signaturerna. Säkerheten i systemet bygger på att det inte går att utifrån en signatur räkna ut vilket lösenord det var som matades in.

En möjlig attack är om man har stora ordböcker eller tabeller med tänkbara lösenord (exempelvis sigge). Orden och potentiella lösenord körs igenom hasfunktionen och jämförs. För att skydda mot denna typ av attacker använder man en extra hemlighet, man saltar hashningen. Dessutom kan man öka styrkan genom att hasha många gånger (ex 1000 ggr i RFC 2898).

Som jag ser det innebär Frankrikes lag att lösenord måste kunna lämnas över, men det innebär inte med automatik att system med hashade lösenord måste frångås eller att lösenord måste vara lagras i klartext. Det enda lagen verkar säga är att lösenord måste kunna lämnas över. Det som krävs för detta är att lösenorden lagras och sedan vid begäran kan tas fram och lämnas över. Men lösenorden kan säkert lagras väl krypterade och skyddade i en databas avsedd för att uppfylla lagkravet samtidigt som hashade lösenord används av det huvudsakliga systemet.

En sådan databas skulle naturligtvis vara väldigt intressant att komma över för den som vill få tag på lösenord, och vi kommer säkert att få se den typen av informationsförluster i och med lagar av den här typen. Men att tro att all form av säkerhet flyger ut genom fönstret och att allt numera måste vara i klartext är nog att ta i.

Har jag fel? Säg gärna till.