En av mina ursäkter för att inte ännu ha skaffat lösenordshanterare har varit att sprida riskerna. Hur säkert det nu är, så finns det ett lösenord som låser upp allt så kan den som på något vis kommer över det lösenordet (keylogger etc.) ställa till maximal skada. Medan om jag har separata lösenord så kan varje intrång göra mer begränsad skada. Det är dock inget starkt argument, för det finns ju många nackdelar med en massa olika lösenord också.
Skrivet av B.Linder:
Well, exakt samma sak kan ju likväl hända bitwarden(minus URLerna då), Kunduppgifter av samma sort har ju dom också utanför användarens valv. "Zero knowledge" används väl av alla lösenordshanterare värda namnet, inget unikt för bitwarden. Att open-source skulle bidra positivt till säkerheten är inte heller något givet.
Skrivet av Homdax:
Har tänkt samma. De visar all kod, vem som helst kan se fel och rätta, men illvilliga får ju reda på exakt hur det funkar och kan klura ut hur man kringgår det. Är inte säker på att jag köper okompilerad öppen kod som något säkrare än kompilerad sluten kod. Fast många påstår ju det...
Är hemlig programkod säkrare än icke-hemlig programkod? Jag tror att svaret i alla praktiska sammanhang är nej, här kommer grunden för varför jag tror så.
Kod är bara så säker som den är skriven. Dåligt skriven kod som är full av säkerhetshål blir ju inte säkrare av att vara öppen, då är det såklart bättre om en anfallare måste gissa sig till säkerhetshålen än om de kan utläsa dem ur koden. Problemet är att kod som är så dåligt skriven kan aldrig bli acceptabelt säker utifrån moderna standader, hur hemlig den än är. För det går alltid att reverse-engineera eller gissa sig till säkerhetshålen. Så även om svaret i detta fall blir ja, så är det inte praktiskt relevant.
Om vi teoretiskt tänker oss ett program som är skrivet enligt konstens alla regler, där säkerheten inte bygger på några hemligheter från koden, utan alla hemligheter lagras separat i form av kryptonycklar eller liknande. Är inte sådan kod fortfarande säkrare om den är hemlig, eftersom det kan finnas buggar som programmeraren missat? Ja, i teorin. Nej, i praktiken, eftersom
På samma sätt som öppen kod kan läsas av anfallare, så kan den läsas av vänligt inställda som kan hjälpa till med att hitta samma buggar. Då open-source-projekt ofta utvecklas organiskt, så hinner många buggar hittas innan mjukvaran fått sådan spridning att en anfallare har något att vinna på att attackera den. Det är en välkänd mekanism som många nämner.
Vad färre tänker på, är att man skriver bättre kod om man vet att jämnbördiga eller bättre programmerare kommer att läsa den. I valet mellan att leta buggar och utveckla nya features skulle de flesta att välja det senare, för ingen gillar att säkra kod i efterhand, eller att lägga till de där röriga if-satserna som hanterar randvillkoren till ens snygga oneliner. Det är otroligt lätt att vänta med buggfixandet med ursäkten att koden ändå inte kan granskas av en anfallare. Sen glöms det bort, programmeraren slutar, och den temporära koden blir legacy. Medan i open-source-fallet vet man att såväl hackers som andra programmerare man respekterar kan se ens misstag och slarv i klartext, och då har man inget annat val än att fixa säkerheten direkt.
Sen finns det ytterligare en aspekt av säkerhet som inte har med kodens kvalitet och funktionsduglighet att göra, och det är att man också måste kunna verifiera säkerheten. Det kan man bara om man kan kontrollera vad programmet gör. Samma sak kan också förstås i termer av tillit. Länken som @Yatagarasu postade ovan nämner både Zero-Knowledge och Zero-Trust. Zero-knowledge går att få till med sluten mjukvara, men inte Zero-trust. För kan du inte läsa koden så måste du lita på att skaparen inte lagt in bakdörrar, vare sig det är pga illvilja, lagkrav eller påtryckningar. Medan om koden är öppen, då behöver utvecklarna inte ens bekymra sig för påtryckningar då sådana skulle vara verkningslösa.
