Bjarke Walling

Man skulle måske overveje om 2FA virkeligt er 2 faktorer, når brugeren kun benytter én enhed, hvor både login foregår og den ekstra faktor (SMS i dette tilfælde) kan verificeres. Hvis mobilen blev stjålet har angriber i teorien kun brug for at bryde adgangskoden inden at SIM-kortet bliver låst.

Jeg synes det er godt, der kommer fokus på stemmestyring. Nogle gange er det hurtigere at sige "Hey, set an alarm for 7 o'clock" end at finde alarm app'en og vælge tid. Desværre er teknologien stadig alt for simpel til at have en "dialog" med sin smartphone på et rimeligt niveau. Jeg kender flere svagtseende personer, og de har langt større mulighed for interaktion og selvstændig mobilitet med stemmestyrede enheder, så det har bestemt positive sider.

Omvendt er det super ærgerligt at det kun er få store virksomheder, som har råd til R&D i god stemmestyring. Eksemplet med Capital One viser at enheder kan indeholde moraliserende svar, og det er et problem, når man som forbruger er "underlagt" et kodeks uden måske at være bevidst om det. Der burde være open source-software, hvor jeg selv kan indlæse de svar/forståelses-moduler, der passer til mine personlige holdninger. Jeg kan i alle fald frygte at vi ender med kun at bruge stemmestyring udviklet i USA og med et specifikt forståelses- og moralkodeks, der ikke stemmer overens med andre verdensdele.

Findes der en Python User Group i Danmark, evt. mere specifikt Århus (for mit vedkommende)? Måske er Version2-gruppen det nærmeste man kommer :-)

Mvh.
Bjarke

En anelse off-topic, og alligevel… Jeg er på Facebook, Google, LinkedIn, osv., fordi det giver en lang række muligheder for kommunikation, communities og netværk på globalt plan. De sociale medier fandtes ikke i det 20. århundrede. De findes nu, og jeg har ikke lyst til at gå tilbage. Mange folk argumenterer, at hvis jeg går ind for privatlivets fred, så kan jeg bare slette mine konti. Der er desværre et manglende fokus på decentralisering af disse systemer. Jeg vil have kontrol over mine egne data, bestemme hvem jeg deler det med og til hvilke formål. Det skal ikke kun være en indstilling, som Facebook har det, hvor dataene stadig ligger i klartekst i et datacenter et ukendt sted i verden. Jeg er bange for, at der ikke er nogen, som (succesfuldt) udvikler et 100% decentralt socialt netværk, da der simpelthen ikke er penge i det. Facebook og Google tjener på at “bryde vores privatliv” på godt og ondt for at profilere og sælge reklamer. Det er derfor, at det ikke koster noget at tilmelde sig disse services. Jeg ville ønske, at der var en simpel løsning.

Hvis det handlede udelukkende om privatliv, så kunne jeg bure mig selv ind i en gummicelle og lade være med at deltage i omverdenen mest muligt. For mig handler det om at maksimere graden af privatliv samtidig med at vi holder fast i vores måde at leve og kommunikere på.

Jeg forstår ikke denne iver efter at centralisere og skabe store mastodont-systemer. Måske er det bare mig, der er naiv, men man burde sætte sig ned i DS e.lign. og definere en data-model/-standard for udveksling af eksamensdata og sige til gymnasierne at de kan vælge et hvilket som helst system, sålænge det er interoperabelt med den givne åbne standard. Det vil være billige, da små spillere kan komme ind og konkurrere på markedet.

Når vi snakker ydelse, så er der nogle algoritmer, som bliver skrevet til GPU'er i enten CUDA eller OpenCL. Alt afhængig af opgaven, så kan de performe væsentlig bedre end programmer skrevet i C++ til CPU'er.

Et sted, hvor citronen virkelig bliver presset i henhold til JS crypto, er HTML5-baserede bitcoin wallets. Folk ønsker ikke at deres nøgle bliver opbevaret på serveren – de stoler ikke på at tredjeparter kan opbevare nøglen sikkert eller af ideologiske hensyn. Omvendt er der åbenlyse udfordringer ved at foretage al crypto client-side. Der er eksempler på folk, der har fået stjålet sine penge af ondsindede browser extensions. Den bedste løsning i dette tilfælde er måske at bruge 2FA / multi-signature, foretage crypto både client- og server-side, lade serveren checke at transaktionen holder sig indenfor foruddefinerede parametre og kun acceptere den, hvis brugeren kan autentificeres ad andre kanaler. Eller lade folk hoste deres egen lokale server.

Jeg begik selv samme fejl engang, men er blevet klogere siden. Jeg hashede passwordet med et timestamp for at man ikke bare kunne genbruge samme token, men det skal bemærkes at man generelt ikke kan lave crypto client-side, så længe at JS-koden ikke serveres over HTTPS.

Det er tidligere blevet debateret på Version2 at de benytter live kode-obfuskering til at skjule en nøgle for at (prøve at) sikre autenticiteten af JavaScript-koden. Det betyder at serveren leverer en ny obfuskeret udgave for hver request og klienten kan ikke cache det.

... hvilket i øvrigt er total absurd for JavaScript leveret til mobile klienter. :-)

1. Vær indvolveret i udviklingen af ny anonymiseringssoftware
2. Inkluder skjulte bagdøre
3. Badmouth samme software offentligt for at få folk til at stole på ægtheden
4. ???
5. PROFIT!!!!

:-)

Jeg forstår ideen, men jeg tror ikke på sikkerheden i praksis. Der findes vel også metoder til at automatisere de-obfuskering, således at et angreb kan foretages inden den indbyggede nøgle i JavaScript-koden udløber. Jeg håber, at de har læst Javascript Cryptography Considered Harmful.

Hvorfor vil du slette cookies automatisk?

Ok, min pointe var ikke at cookies altid skal slettes automatisk, men at give brugeren et valg om dette. F.eks. bruger jeg ofte Private Browsing / Incognito, hvis der lige er noget, hvor jeg gerne vil være sikker på at gamle cookies ikke sendes med. Jeg tror på at vi kan skabe bedre UX i browseren mht. privacy, så folk kan træffe deres eget valg.

Lige nu kigger Erhvervsstyrelsen på device fingerprinting i henhold til cookie-lovgivningen. Hvis de skal gennemgå alle teknologier, som kan bruges til at tracke browsere, så kommer det til at tage et par år og vi ender ikke op med at det beskytter brugerne bedre. Derfor synes jeg, at det er vigtigere at kigge på tekniske løsninger, som vil hjælpe hurtigere og bedre.

Se f.eks. http://lucb1e.com/rp/cookielesscookies/ ... hvis det minder for meget om cookies, hvad med tracking via HTML5 AppCache manifest. Alle caching-mekanismer i browseren, som har interface til HTTP kan bruges til tracking på den ene eller anden måde. I stedet for at lovgive på området, så bør vi rådgive folk om tekniske løsninger, f.eks. at browsere sletter cookies oftere/automatisk osv.

En bedre løsning ville være at signere og tidsstemple dokumentet med en service a la BTProof. Det koster 1 satoshi (mindre end 1/100 øre). En ting, som bitcoin kan bruges til, er at gemme hashes i en given blok og du kan derved bevise at dokumentet var til stede på dette tidspunkt. Det er et distribueret system og sikrer at regeringer ikke kan fifle med dine dokumenter bag om ryggen på dig. Jeg tror dog ikke det er afprøvet i nogle retsager endnu, men ideen er interessant.

Du kan snildt udvide den til:

if (a && a.length) {
  // ...
}

(selv foretrækker jeg a.length > 0 for at være en anelse mere eksplicit).

Her er nogle tricks, som jeg ofte bruger:

// Vær sikker på at a er en integer (eller 0, hvis den ikke kan fortolkes).
a = a | 0;
 
// Konverter b til en streng, men sørg for at null/undefined bliver en tom streng.
b = ('' + [b]);
 
// sæt en default-værdi for value, hvis den er "falsy".
value = value || 'foo';

Det er meget praktisk, når man kender dem (og derved kan læse koden).

Jeg har set nogen tilføje et "pepper", som er gemt i applikationskoden – saltet er i databasen. Det leder frem til spørgsmålet om det er marginalt mindre sandsynligt at applikationskoden og databasen bliver lækket samtidigt end hver for sig. I mange tilfælde er det nok ikke, hvis det hele er hostet på én maskine.

Kig også på Scrypt: http://en.wikipedia.org/wiki/Scrypt

Den har tre parametre: CPU-forbrug, hukommelses-forbrug og parallelisering. Den er designet til at være svær at implementere i hardware. Man vinder ikke særlig meget ved at lave en ASIC i forhold til at implementere algoritmen på en CPU.

I øvrigt en rigtig fin artikel. :-)

I har ret... det er redesign, der er brug for. Jeg har nok bare brugt ordet refactoring i flæng til forbedringer af systemer.

Jeg har selv penderkort, og jeg glæder mig ikke til at det bliver erstattet af rejsekort, hvor man skal huske at tjekke ind og ud hele tiden. Det kan godt være det er en lille ting, men jeg synes de skulle have lavet lidt interaktionsdesign og brugerstudier på rejseforløbet med et rejsekort.

Et rimelig kendt begreb i it, måske skal vi bare være bedre til at gøre det på forretnings-niveau i stedet for udelukkende kode-niveau. Det tænker jeg i alle fald, når man hører om nye offentlige systemer (ikke kun it-systemer).