mboost-dp1

lastpass læk sårbarhed afslører password tjeneste populær / Newz.dk

LastPass

Lastpass Hack fra August eskalerer

- , indsendt af arne_v

Hacket Lastpass oplevede i August, viser sig nu at indeholde følsomme oplysninger, trods Lastpass’ melding om det modsatte.

Lastpass der opbevarer oplysninger på vegne af over 33 millioner brugere og 100.000 virksomheder, blev i august i år udsat for et hack.

Dengang forsikrede Lastpass om, at der ikke var fundet beviser for at at personlige oplysninger blev lækket.

Nu viser det sig at faktureringsadresser, e-mail-addresser, telefonnumre og IP-addresser er en del af lækket.

 





Gå til bund
Gravatar #1 - DrHouseDK
2. jan. 2023 13:58
Mon ikke det ender med at de også afslører at passwords er smuttet sig en tur...
Gravatar #2 - Mr.Smiley
3. jan. 2023 02:35
#1 - Det kunne faktisk godt lyde lidt sådan, omend stadig krypteret (?).

Fra Version2 (kilden til dette):
"Hackerne kopierede ifølge Ars Technica også en sikkerhedskopi af kodeboksdata, der inkluderede ukrypterede data som hjemmesiders URL'er og krypterede datafelter som brugernavne og adgangskoder til hjemmesider, sikre noter og formularudfyldte data."
Gravatar #3 - arne_v
3. jan. 2023 02:58
#1 og #2

Ja.


Not literally on the night before Christmas, but perilously close to it, LastPass admitted that:

The threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service.

Loosely speaking, the crooks now know who you are, where you live, which computers on the internet are yours, and how to contact you electronically.

The admission continues:

The threat actor was also able to copy a backup of customer vault data.

So, the crooks did steal those password vaults after all.



As an example of what not to do, consider the recent LastPass announcement that its customers’ backed-up password vaults had been stolen, despite the company’s initial assumption that they hadn’t.

LastPass claims to use 100,100 iterations of the HMAC-SHA256 algorithm in its PBKDF2 password generation process (we currently recommend 200,000, and OWASP apparently recommends 310,000, but let’s accept “more than 100,000” as satisfactory, if not exemplary)…

…but that’s only for master passwords created since 2018.

It seems that the company never got round to advising users with master passwords created before then that theirs had been processed with just 5000 iterations, let alone requiring them to change their passwords and thereby to adopt the new iteration strength.

This leaves older passwords at much greater risk of exposure to attackers using contemporary cracking tools.

Gravatar #4 - fastwrite_1
3. jan. 2023 11:52
Har I et godt alternativ til LastPass?
Har brugt den i årevis..
Gravatar #5 - fastwrite_1
3. jan. 2023 12:21
Hm, lader til at 1password kunne være et godt alternativ.
Gravatar #6 - DrHouseDK
3. jan. 2023 12:49
fastwrite_1 (5) skrev:
Hm, lader til at 1password kunne være et godt alternativ.

Jeg erstattede Lastpass med 1Password. :-) Jeg er rigtig glad (for 1Password...)
Gravatar #7 - DrHouseDK
3. jan. 2023 12:50
arne_v (3) skrev:
#1 og #2

Ja.


Rigtig fine citater


Jeg bliver simpelthen så træt. Men det er et godt eksempel på værdien af MFA.
Gravatar #8 - Hack4Crack
3. jan. 2023 14:34
Troede ellers at hacket tjenester efterfølgende blev forbedret, og de mest sikre, men det er så ikke tilfældet.

Lynet slår sjælden ned det samme sted to gange, men det gør det så i LastPass tilfælde.
Gravatar #9 - Athinira
3. jan. 2023 16:43
fastwrite_1 (4) skrev:
Har I et godt alternativ til LastPass?
Har brugt den i årevis..


Jeg bruger en Open Source app kaldet Keepass og har brugt den i mange år. Og er fuldt tilfreds med den. Jeg bruger version 2 (de har også en version 1).

Selve password-filen (som er fuldt krypteret fra start til slut) gemmer jeg på Dropbox, og den kan også tilgås fra en mobilapp (jeg bruger Keepass2Android, men der er flere alternativer, også til iOS). Ligeledes er der Open Source ports til Mac/OSX.

På min computer kan min browser tilgå Databasen via en browsertilføjelse. I selve Keepass har jeg en tilføjelse kaldet KeePassHTTP, og i Chrome har jeg så KeePassHTTP-Connector.

På PC har appen mange gode features, inkl. memory-encryption, synkronisering af databaser (så hvis du gemmer en database på en computer mens den er åben på en anden, så finder appen ud af det, og synkroniserer de to databaser automatisk), indtastning af password på Secure Desktop i Windows. Det er alt i alt er ganske velgennemført Open Source-projekt som stadigvæk varetages.
Gravatar #11 - larsp
3. jan. 2023 18:29
arne_v (10) skrev:
#9

Keepass havde en lille CVE i foråret.

https://nvd.nist.gov/vuln/detail/CVE-2022-0725

https://github.com/ByteHackr/keepass_poc

A flaw was found in keepass. The vulnerability occurs due to logging the plain text passwords in system log and leads to an Information Exposure vulnerability. This flaw allows an attacker to interact and read sensitive passwords and logs.

W...T...F......
NOTE: Vulnerability Only Present in KeePass. Not in KeePassXC and Other Packages

Pyh. Men jeg er så tæt på at skrive min egen password manager. Det var da helt utroligt.
Gravatar #12 - Athinira
3. jan. 2023 18:38
arne_v (10) skrev:
#9

Keepass havde en lille CVE i foråret.

https://nvd.nist.gov/vuln/detail/CVE-2022-0725

https://github.com/ByteHackr/keepass_poc


Så vidt jeg kan se gælder den kun for Linux. Jeg benytter ikke Linux, så ikke et problem for mig - men bestemt ikke heldigt. Keepass er oprindeligt skrevet til Windows, og alle andre versioner er forks.

Buggen er, så vidt jeg kan se, også baseret på at man kopierer et password til udklipsholderen (det ene link du henviser til siger at man skal "dobbeltklikke" et password, men det kopierer også et password til udklipsholderen i Keepass).

Det siger lidt sig selv at hvis din metode til at indtaste et password er at kopiere det til udklipsholderen, så er der mulighed for at andre ondsindede programmer kan læse passwordet. Jeg kan ikke helt se hvordan det er anderledes for nogen anden password-manager. Problemet her ser ud til at Keepass funktion som automatisk rydder udklipsholderen ikke fjerner det fra systemloggen i Linux, men jeg kan ikke se hvordan det er mindre sikkert end password-managers som ikke har en automatisk rydning af udklipsholder-funktion.

Så jeg føler lidt du er med til at sprede en frygt her som ikke behøves at blive spredt. Læs evt. kommentarerne omkring den CVE hos BugZilla:
Thanks for all the provided information. If I am able to reproduce (currently I am not), then I will definititely create a patch to fix it and let you know here.
Gravatar #13 - larsp
3. jan. 2023 18:54
#12 Nu har jeg ikke sat mig grundigt ind i problemstillingen, men de ville overraske mig ret meget hvis et Linux desktop environment kunne finde på at logge i system log alt der kopieres med clipboardet. Det ville være et sikkerhedsproblem næsten på linje med keyloggers.

Jeg tænker at buggen er specifik for omtalte version af keepass.

Linux KeepassXC kopierer også password med clipboard og har ikke dette problem. Efter 10 sekunder bliver clipboarded clearet, så det er marginalt bedre end manual copy paste af et password. Men ja, hvis man har noget malware installeret der logger clipboard indhold er det ret skidt.
Gravatar #14 - Athinira
3. jan. 2023 19:36
larsp (13) skrev:
Linux KeepassXC kopierer også password med clipboard og har ikke dette problem. Efter 10 sekunder bliver clipboarded clearet, så det er marginalt bedre end manual copy paste af et password. Men ja, hvis man har noget malware installeret der logger clipboard indhold er det ret skidt.


Nu har jeg læst lidt rundt i tidligere bug reports som er en replika af denne, og her ser det ud til at det er noget som er specifikt omkring Fedora.

Årsagen til at det ikke rammer alle versioner af Keepass er at den normale version af Keepass benytter Mono i Linux, og fejlen ligger et eller andet sted deri. Det kan ikke fikses i selve KeePass, udover at udskifte brugen af Mono - så kan man altid diskutere hvor fejlen ligger (Keepass eller Fedora/Mono).
Gravatar #15 - arne_v
3. jan. 2023 20:18
#11 #12 #13 #14

Standard KeePass understøtter officelt Linux - det er ikke en fork.

https://keepass.info/help/v2/setup.html#mono
https://keepass.info/help/v2/setup.html#wine

Men KeePass er en .NET (C#) Win Forms applikation.

Mono understøtter Win Forms (ikke godt, men ...).

(.NET Core og .NET 5+ understøtter derimod ikke Win Forms kun WPF så det er ikke en mulighed)

Selvfølgelig er der andre muligheder for GUI framework - GTK#, MAUI etc..

Et eller andet i Mono Win Forms implementering logger tilsyneladende clipboard operationer.

Jeg er sikker på at både log niveau og log destination kan konfigureres. Men sammenhængen mellem den konfiguration og hvorvidt ens password manager skriver ens password i klar tekst til system loggen er ikke åbenlys for alle brugere.

Linux distroen (ikke kun Fedora men også andre) kan ikke gøre andet end at fraråde brug af KeePass.

Mono kan ikke fjerne muligheden for at logge alt hvad der sker. Det ville blive meget sværere at debugge en Mono applikation.

KeePass kunne overveje at udskifte Win Forms med f.eks. MAUI i en version 3.x, men det er en stor ændring.

Hvad KeePass kunne gøre var at lade programmet i tilfælde af at der bruger Mono checke log niveau og log destination og give en besked til brugeren hvis det er for farligt at bruge programmet!

Gravatar #16 - Athinira
3. jan. 2023 22:01
arne_v (15) skrev:
#11 #12 #13 #14

Standard KeePass understøtter officelt Linux - det er ikke en fork.


Min fejl. Tak for rettelsen.

arne_v (15) skrev:
Jeg er sikker på at både log niveau og log destination kan konfigureres. Men sammenhængen mellem den konfiguration og hvorvidt ens password manager skriver ens password i klar tekst til system loggen er ikke åbenlys for alle brugere.


Jf. Keepass-udviklerne så kan det ikke rettes i selve applikationen (uden at ændre brugen af Mono til noget andet, eller som du selv nævner konfigurere Mono anderledes). Så vidt jeg kan forstå så ligger dette ikke i selve Keepass-applikationen.

Alt i alt er det et uheldigt sammenfald.

arne_v (15) skrev:
Hvad KeePass kunne gøre var at lade programmet i tilfælde af at der bruger Mono checke log niveau og log destination og give en besked til brugeren hvis det er for farligt at bruge programmet!


Sandt, men det virker desværre ikke til at de er interesserede i at gøre dette. Ærgeligt, men så kan man heldigvis vælge andre forks af KeePass, eller ignorere det hvis man ikke bruger Linux alligevel.

Dog synes jeg naturligvis også det er kritisabelt at en applikation som er designet omkring sikkerhed ikke får rettet dette. Argumentet synes at være at applikationen som udgangspunkt er lavet til Windows, og det er jo i sig selv fair nok - bare ikke heldigt når sådan nogle sager opstår.

Men jeg vil stadigvæk påstå at KeePass er et sikkert valg, i og med at det er et bredt projekt med mange forks, og man derfor har en god portion valgmuligheder og alternativer på forskellige platforme, og man kan migrere mellem disse uden problemer. Og som udgangspunkt synes jeg at sikkerhedsimplementationen i Windows ser ganske velovervejet ud, og derfor stoler jeg på det.

Set ift. kommercielle løsninger som LastPass, så er der i sidstenævnte tilfælde som den har sag viser jo også andre ting på spil, fx ens private oplysninger, data, hævekortoplysninger etc.

Jeg har selv prøvet at få mit hævekort misbrugt uden at det har været stjålet, jeg har delt oplysningerne med andre, og uden at have handlet på lyssky hjemmesider med det (jeg bruger typisk MobilePay, PayPal og Google Pay hvor-end jeg kan). Min eneste konklusion er at en eller anden hjemmeside jeg har handlet på har sløset med sikkerheden.
Gravatar #17 - arne_v
4. jan. 2023 01:12
Jeg kunne naturligvis ikke lade være med at teste.


using System;
using System.Windows.Forms;

namespace E
{
public class Program
{
[STAThread]
public static void Main(string[] args)
{
Console.WriteLine("{0} ({1} bit)", Environment.Version, IntPtr.Size * 8);
Clipboard.SetData(DataFormats.Text, "Super hemmeligt password");
string txt = (string)Clipboard.GetData(DataFormats.Text);
Console.WriteLine(txt);
Clipboard.Clear();
bool clr = Clipboard.ContainsData(DataFormats.Text);
Console.WriteLine(clr);
}
}
}


skriver selvfølgelig ikke password ud på Windows.

På Ubuntu med Mono skriver den heller ikke noget ud som default.

Men en:

export MONO_LOG_LEVEL=debug

og så spytter den et hav af debug ud men kun passwordet en gang d.v.s ikke i debug.

Så der må skulle lidt mere til.
Gravatar #18 - arne_v
4. jan. 2023 01:35
#17

Efter at have kigget lidt på den famøse log så tror jeg ikke at logningen sker i Mono men i Qt.

Stakken er:

application--Mono Win Forms--Qt--X11

Qt debug kontrolleres af environment variabel:

QT_LOGGING_RULES

Men jeg er desværre ikke Qt (KDE) kyndig nok til at kunne teste det.
Gravatar #19 - DrHouseDK
4. jan. 2023 12:16
Jeg synes dog KeePass er for kluntet med opbevaring af fil. Det er i min optik sådan lidt nørdet "for at være nørdet". Jeg er bevidst om at en KeePass-bruger vil være uenig. ;P
Gravatar #20 - Athinira
4. jan. 2023 13:20
DrHouseDK (19) skrev:
Jeg synes dog KeePass er for kluntet med opbevaring af fil. Det er i min optik sådan lidt nørdet "for at være nørdet". Jeg er bevidst om at en KeePass-bruger vil være uenig. ;P

Den må du gerne uddybe. Du vælger et sted at gemme filen - i mit tilfælde gemmer jeg den i Dropbox.

På mine forskellige computere bliver filen derfor automatisk opdateret når jeg foretager ændringer, og på min telefon kan min app også automatisk tilgå filen direkte i Dropbox.

Eneste irritationsmoment er at jeg skal indtaste adgangskoden hver gang jeg (gen)starter computeren. Det er lidt irriterende, men hvis alternativet er et sikkerhedsbrud som det vi ser i nyheden her, så tager jeg det sgu over LastPass any day of the week :o)
Gravatar #21 - chris
4. jan. 2023 13:27
Lige nu er jeg taknemmelig for at jeg har mit eget domæne og derfor har kunnet lave unikke emailadresser og passwords til hver konto jeg har oprettet de sidste mange år.
Fordi det gør det om ikke andet sværere at bruge 1 cracket password til noget som helst.
- hvis de krakker dem allesammen er det jo ligemeget, men det køber tid.

Ulempen
Nu skal jeg så til at ændre email-adresser og passwords på 488 forskellige hjemmesider, apps og tjenester, yikes!

Det var åbentbart ikke et "hack" som i at Lastpasses implementering af software var hullet.
Det var noget så simpelt som social engineering og spearfishing.
Og den slags er desværre meget sværere at få bugt med, da det ikke kan løses med matematik.

Men nu bliver det jo så spændende at se om deres "Zero Knowledge architecture" faktisk virker i virkeligheden.
Gravatar #22 - larsp
4. jan. 2023 13:36
arne_v (18) skrev:
Efter at have kigget lidt på den famøse log så tror jeg ikke at logningen sker i Mono men i Qt.

Stakken er:

application--Mono Win Forms--Qt--X11

Qt? Heh, den oprindelige version 1 af KeePass er et C++/Qt4 program med native klienter til de fleste platforme. Jeg brugte det i mange år og håber sgu ikke det loggede mine passwords i systemlog hele vejen... :P

Men det er lettere forvirrende med alle de versioner. Følgende er mit bedste bud på et overblik:

KeePass v1: C++/Qt4
KeePass v2 (Windows): C#/WinForms
KeePass v2 (Linux): C#/Mono WinForms/Qt/X11 (pust)
KeePassX (fork af KeePass v1, men projektet er temmelig dødt)
KeePassXC (fork af KeePassX): C++/Qt5

KeePassX og KeePassXC er ikke officielle releases men community forks. KeePass v2 er den officielle desktopklient, men ikke anbefalelsesværdig på Linux i lyset af denne diskussion!

DrHouseDK (19) skrev:
Jeg synes dog KeePass er for kluntet med opbevaring af fil. Det er i min optik sådan lidt nørdet "for at være nørdet". Jeg er bevidst om at en KeePass-bruger vil være uenig. ;P
Opbevaring af fil, hvad mener du? KeePass* kan enten åbnes som en association til en kdb fil eller hvis man starter programmet direkte, kan man vælge blandt de senest åbnede kdb filer.

Det er ikke nørdet for at være nørdet, det er sådan man har arbejdet med filer de sidste 30 år ;)

Cloud storage af password derimod ... Det ville være "moderne for at være moderne" og ikke noget jeg ville bruge personligt. Men jeg er også gammeldags og en af de få der nægter at installere f.eks. web bank apps på smartphone. Stoler absolut ikke på en smartphone til noget der kræver reel sikkerhed.
Gravatar #23 - larsp
4. jan. 2023 14:01
PS. Efter at have læst lidt op på tingene må jeg sige, at jeg er godt tilfreds med at have valgt KeePassXC (efter KeePass v1). Der er en masse sund fornuft i svarene i deres FAQ: https://keepassxc.org/docs/ f.eks. den her:
Q: Does KeePassXC support (KeePass2) plugins?
A: No, KeePassXC does not support plugins at the moment and probably never will. KeePassXC already provides many of the features that need third-party plugins in KeePass2 out of the box, so for most things you don't even need plugins, nor should you ever want them. Plugins are inherently dangerous. Many KeePass2 plugins are barely maintained (if at all), some have known vulnerabilities that have never been (and probably never will be) fixed, and none of them are as thoroughly tested and reviewed as we test and review code that goes into our main application. We find that encouraging users to install untested (and often quickly-abandoned) third-party plugins is inherently incompatible with the security demands of a password manager. If you really need external functionality not available in KeePassXC, you can look for "plugins" that use the KeePassXC-Browser API, which is a much more secure way of sharing passwords with third-party applications than loading those applications as plugins directly into KeePassXC.
Så KeePass v2 har åbenbart et plugin system. Tsk tsk tsk. Det er jo creeping featuritis så det batter, og den slags hører bare ikke hjemme i en password manager.
Gravatar #24 - Athinira
4. jan. 2023 15:37
larsp (23) skrev:
Så KeePass v2 har åbenbart et plugin system. Tsk tsk tsk. Det er jo creeping featuritis så det batter, og den slags hører bare ikke hjemme i en password manager.

Det kan altid diskuteres. Det er vel op til den individuelle bruger. Selvfølgelig er det ikke nødvendigvis en god ide at benytte plugins som aldrig opdateres, men i sidste ende er du jo nødt til at stole på folk der skriver din software, uanset om det er KeePass, KeePassXC eller/og pluginudviklere.

For at KeePassXC skal virke i browsere skal de for øvrigt også bruge en browser-extension. Der henviser de til KeePassHTTP-Connector - samme som jeg bruger til mit plugin til KeePass 2. Udover at browserextensions per definition også er plugins, så har denne extension som de henviser til heller ikke været opdateret siden 2018.

Så hvis manglen på opdateringer og brugen af plugins er kritisable punkter, så flyver begge punkter altså direkte tilbage og rammer dem i hovedet som en boomerang her.
Gravatar #25 - arne_v
4. jan. 2023 15:49
Jeg er ikke kompetent til at vurdere denne her artikel men Bruce Schneier har anbefalet den:

https://stuartschechter.medium.com/before-you-use-...
Gravatar #26 - larsp
4. jan. 2023 17:12
Athinira (24) skrev:
Det kan altid diskuteres. Det er vel op til den individuelle bruger. Selvfølgelig er det ikke nødvendigvis en god ide at benytte plugins som aldrig opdateres, men i sidste ende er du jo nødt til at stole på folk der skriver din software, uanset om det er KeePass, KeePassXC eller/og pluginudviklere.
Ja, den kode der kører i et password wallet program er noget man skal kunne stole på til højeste grad, og derfor er én udvikler med review og test procedurer bedre end dertil at have en bunke tilfældige pluginudviklere. Jeg håber (meget) at KeePass2's plugin system har noget sikker signering af pluginkode så malware ikke lige kan snige en plugin ind fra siden der stjæler hele pivtøjet.

Angående browser auto fill plugins, can't help, det har jeg aldrig brugt. Jeg lader ikke min browser udfylde logins eller huske passwords generelt, men accepterer at sites jeg logger ind på gemmer en session cookie. Når den så løber ud, må jeg have fat i keepass igen. Dermed ikke sagt at mit approach er bedre eller mere sikkert overordnet set...
Gravatar #27 - Athinira
4. jan. 2023 18:07
larsp (26) skrev:
Ja, den kode der kører i et password wallet program er noget man skal kunne stole på til højeste grad, og derfor er én udvikler med review og test procedurer bedre end dertil at have en bunke tilfældige pluginudviklere. Jeg håber (meget) at KeePass2's plugin system har noget sikker signering af pluginkode så malware ikke lige kan snige en plugin ind fra siden der stjæler hele pivtøjet.
Igen, det kan du argumentere for med alt software som har Plugins. Firefox har Plugins. Chrome har Plugins. Microsoft Edge har plugins. Det forhindrer ikke folk i at bruge dem, eller anbefale at bruge dem. Og hvis de kan, så kan KeePass også.

Browsere er sgu også sikkerhedskritiske applikationer, da vi bruger dem til mange sikkerhedskritiske ting. Vi ordner vores Netbankforretninger i dem. Vi indtaster vores kreditkort i dem når vi shopper online. Vi indtaster vores adgangskoder i dem. Hvorfor er det ikke i orden at en password-manager bruger plugins, men browsere gør?

KeePass plugins er baseret på filer (der er en fysisk fil for et plugin). Du kan skrivebeskytte disse filer, så malware ikke kan erstatte dem uden administratorprivilegier.

De fleste - hvis ikke alle - KeePass-plugins er Open Source, og du kan derfor selv se koden og alternativt kompilere dem selv.

Min pointe er at det ikke er så stor en sikkerhedsrisiko som folk gør det til ift. mange andre ting.

Derudover så påpeger jeg KeePassXCs dobbeltmoral i at fraråde outdatede plugins med den ene hånd, men samtidigt anbefale dem med den anden. Hvis outdatede plugins er så stort et problem, så burde de fikse den del af deres anbefalinger - fx ved at udvikle deres eget alternativ til KeePassHTTP-connector som de så sideløbende kan holde opdateret. Det de gør her er intet andet end god gammeldags hykleri.
Gravatar #28 - sand
5. jan. 2023 00:19
Jeg bruger Bitwarden, som jeg skiftede til efter at have brugt Keypass et par år, men sync gennem Google Drive eller OneDrive eller min Synology Nas gik som regel galt før eller siden. Så jeg kiggede mig om efter et godt alternativ der IKKE hed LastPass...

Er godt tilfreds med Bitwarden og kan dele udvalgte data med ungerne og fruen.
Gravatar #29 - fastwrite_1
5. jan. 2023 00:55
Jeg har mistet al tiltro til password managers.

Gad vide om man skulle lave sig en Excel fil med koderne i stedet, og gemme denne fil på en lokal computer som ikke har internet adgang.
Gravatar #30 - Athinira
5. jan. 2023 01:28
sand (28) skrev:
Jeg bruger Bitwarden, som jeg skiftede til efter at have brugt Keypass et par år, men sync gennem Google Drive eller OneDrive eller min Synology Nas gik som regel galt før eller siden. Så jeg kiggede mig om efter et godt alternativ der IKKE hed LastPass...

Er godt tilfreds med Bitwarden og kan dele udvalgte data med ungerne og fruen.

Jeg fatter stadigvæk ikke den med at sync "Gik galt" med KeePass her.

Hvis jeg forsøger at gemme en ændring i Keepass-databasen på en enhed, men har ændret databasen på en anden enhed, så opdager Keepass det selv, og spørger om jeg vil synkronisere ændringen. Det har aldrig skabt problemer, og fungerer både på mine PC'er og min telefon-app.



Når det så er sagt, så ser Bitwarden interessant ud. Jeg vil tjekke det :-)
Gravatar #31 - larsp
5. jan. 2023 07:13
Athinira (27) skrev:
Browsere er sgu også sikkerhedskritiske applikationer, da vi bruger dem til mange sikkerhedskritiske ting. Vi ordner vores Netbankforretninger i dem. Vi indtaster vores kreditkort i dem når vi shopper online. Vi indtaster vores adgangskoder i dem. Hvorfor er det ikke i orden at en password-manager bruger plugins, men browsere gør?

Ja, browsere er også sikkerhedskritiske applikationer, i højeste grad. Derfor har jeg flere browsere installeret, eg. Chromium, Firefox, Opera, og bruger dem til forskellige formål. Én browser er så clean som muligt og bliver brugt til web bank og lignende. Denne browser har ikke installeret plugins! En anden browser bruges til generel browsing, og en trejde får den hårdt bagfra med de ondeste session cookies fra eg. Facebook og Google. Men da jeg ikke bruger den trejde browser til generel browsing minimerer det hvad disse konglomerater kan tracke om mig. Det er småirriterende at holde styr på nogle gange, men sund fornuft IMO.
Min pointe er at det ikke er så stor en sikkerhedsrisiko som folk gør det til ift. mange andre ting.
Måske. Men at andre ting er lidt usikkre alligevel er ikke godt argument for at sænke kravene til hvad der kan få lov at tilgå det helligste af det helligste, som er hele samlingen af passwords i en wallet.

Look. Vi har alle udviklet vores egne principper og teknikker til at holde styr på ting som passwords, som matcher vores risikotolerance. Jeg siger ikke at plugins generelt er udelukket mht. password. De er sikkert smarte og gode til mange formål. Danske web banker kræver alligevel MitID før der kan laves en transaktion, så selv web bank login breach har road blocks før den helt store skade kan ske. (Edit: det er selvfølgelig noget vrøvl, jeg blander sammen med udenlandske banker der typisk kun har et simpelt username/password login for at komme ind, men derefter to eller tre faktor auth til at godkende en transaktion)

For mit vedkommende har jeg ting liggende i (særlige) password wallet filer som vil kunne give en hacker adgang til store midler UDEN ekstra road blocks. Ingen tilfældig plugin slamkode skal have mulighed for at snuse rundt der. Så jeg har måske ekstra paranoia på visse fronter.
Gravatar #32 - Mock
5. jan. 2023 10:02
Jeg har selv kigget på alternativer. og hvis det kommer til man bare som privatbruger søger alternativ så ville jeg nok rate dem i denne rækkefølge

1Password
Bitwarden
Dashlane
Google Chrome
Keepass

Selv kan jeg godt klare mig med chrome password manager, som ikke har det fedeste feature set. men klare opgaven til privat brug. til erhverv står den desværre stadig på lastpass da der er nogle enterprise features vi ikke finder i de andre produkter.

og når det kommer til privat brug så lyder det til største delen er glade for 1password grundet en god UI som skulle slå LP med mange længder. og have bedre autofill. men prisen skulle også være den højeste.

anbefalinger hvis man ønsker at kører videre med LP
skift master password og overhold deres password politik med minimum 12 karakter, og samtidig skift alle passwords, da der kan bruteforces adgang til selve passwords. medmindre man har et stærkt password der allerede bygger på anbefalingerne
Gravatar #33 - Athinira
5. jan. 2023 10:23
larsp (31) skrev:
Ja, browsere er også sikkerhedskritiske applikationer, i højeste grad. Derfor har jeg flere browsere installeret, eg. Chromium, Firefox, Opera, og bruger dem til forskellige formål. Én browser er så clean som muligt og bliver brugt til web bank og lignende. Denne browser har ikke installeret plugins! En anden browser bruges til generel browsing, og en trejde får den hårdt bagfra med de ondeste session cookies fra eg. Facebook og Google. Men da jeg ikke bruger den trejde browser til generel browsing minimerer det hvad disse konglomerater kan tracke om mig. Det er småirriterende at holde styr på nogle gange, men sund fornuft IMO.

Dette er så din - ja undskyld udtrykket - sølvpapirstilgang til browsing. Det gælder for dig og måske 0.01% af folk.

I mellemtiden bruger alle andre typisk en browser, gerne med plugins, og får ikke deres data kompromitteret via. plugins. Typisk bliver folk kompromitteret af andre veje - fx illegale wares fra PirateBay eller via. phishing.

Der er ingen som betvivler at plugin-funktionalitet kan være en sikkerhedsrisiko.
Men i praksis tror jeg det er de færreste datalæk der sker på den måde for private personer (for virksomheder kan det være en anden sag, siden hackere der har et større mål for øje typisk typisk er mere velorganiserede og klar til at bruge meget specifikke metoder for at opnå det de ønsker).

I sidste ende kommer det jo ned til det jeg sagde tidligere: Det handler om hvor vidt man stoler på dem der skriver ens software.

I forbindelse med KeePassXC-citatet blev jeg blot irriteret, fordi de er dobbeltmoralske ud fra de kriterier jeg påpegede. Det har selvfølgelig ikke noget med dig at gøre.
Gravatar #34 - Athinira
5. jan. 2023 10:42
Mock (32) skrev:
Jeg har selv kigget på alternativer. og hvis det kommer til man bare som privatbruger søger alternativ så ville jeg nok rate dem i denne rækkefølge

1Password
Bitwarden
Dashlane
Google Chrome
Keepass

Selv kan jeg godt klare mig med chrome password manager, som ikke har det fedeste feature set. men klare opgaven til privat brug. til erhverv står den desværre stadig på lastpass da der er nogle enterprise features vi ikke finder i de andre produkter.


Jeg valgte selv at tjekke BitWarden ud efter anbefalingen fra #28. Jeg kan godt lide at de båder tilbyder at man kan tilkøbe deres løsning, men også kan self-hoste den gratis. Jeg valgte at prøve den af via. self-hosting på min Synology NAS, og fik nemt systemet op at køre og op på mit underdomæne hvor jeg kan tilgå det via. en URL.

Desværre vil jeg til mine formål ikke rate det, eller andre af de udbydere du nævner, over KeePass af 4 årsager:

1) Mangel på understøttelse af separate databaser/databasefiler.
Jeg benytter 2 forskellige databasefiler til KeePass, en til über-sikre passwords som jeg ikke altid har åben (tænk krypteringsnøgler mm.), og en til almindelige passwords.

Teknisk set kunne man have to forskellige konti, men jeg kan ikke umiddelbart se at programmet understøtter at man kan være logget ind på begge disse kontis samtidigt.

2) Det kører via. web, hvilket introducerer SSL/TLS som en risikofaktor
Aka. du skal stole fuldt på SSL/TLS-protokollen.

Der er vi et eller andet sted tilbage til diskussionen mellem Larsp og mig. Hvor han ikke stoler på plugins, så stoler jeg generelt ikke på at SSL og hele certifikat-systemet ikke kan undermineres. Det er blevet gjort mange gange.

3) Hvis du ikke self-hoster, så ligger du dine data i hænderne på endnu et firma
Med andre ord, så er vi tilbage til LastPass-problematikken fra den her artikel. Du skal både stole på at de beskytter dine data, men også at de benytter en sikkerhedsstandard der er op to scratch.

Med KeePass har jeg lige fra starten fx selv kunne vælge antallet af key iterations og sætte det højt, mens LastPass jo her demonstrerer at de ikke altid har gjort det, og dermed er nogle af deres brugere nu udsat for risiko.

4) Hvis du self-hoster er korrekt backup af databasen en bekymring
Denne bekymring slipper jeg for ved at opbevare mine KeePass-databasefiler i Dropbox. Jeg kan genoprette tidligere versioner af filerne fra DropBox. Jeg kan altid tilgå dem i min DropBox. Skulle min DropBox-konto blive lukket, så har jeg stadigvæk lokale versioner af filerne synkroniseret til mine computere. Og jeg behøves ikke bekymre mig om sikkerheden i Dropbox, da filerne er fuldt krypterede og ikke engang metadata er beliggende i dem. Så selv hvis min Dropbox bliver kompromitteret, så kan de ikke gøre noget med selve filerne når de ikke kan dekryptere dem.

Løsningen er med andre ord overordentlig simpel og til at forstå for de fleste der kan lidt med computere, og dermed minimeres risikoen for fejl. Korrekt backup af en self-hosted BitWarden database kan derimod være lidt mere kompliceret. Går databasen i stykker hvis strømmen til min NAS ryger fx?

I sidste ende er KeePass den eneste løsning hvor jeg både er tryg ved at jeg ved at jeg altid har en backup af mine password-databaser, og jeg ved at jeg ikke skal lægge mine data (eller mine passwords) hos andre.
Gravatar #35 - arne_v
5. jan. 2023 15:00
Athinira (34) skrev:

2) Det kører via. web, hvilket introducerer SSL/TLS som en risikofaktor
Aka. du skal stole fuldt på SSL/TLS-protokollen.

Der er vi et eller andet sted tilbage til diskussionen mellem Larsp og mig. Hvor han ikke stoler på plugins, så stoler jeg generelt ikke på at SSL og hele certifikat-systemet ikke kan undermineres. Det er blevet gjort mange gange.


Hvor stor en procentdel af de steder hvor du bruger et password hentet fra password manager bliver det sendt over SSL/TLS?
Gravatar #36 - Athinira
5. jan. 2023 23:10
arne_v (35) skrev:
Hvor stor en procentdel af de steder hvor du bruger et password hentet fra password manager bliver det sendt over SSL/TLS?

Det er ikke det individuelle password jeg er bekymret for - det er hele databasen og mit master password.

At individuelle passwords til individuelle kontis som jeg henter bliver sendt til forskellige domæner på forskellige tidspunkter har jeg intet problem med.

At mit master password derimod kan blive kompromitteret over SSL har jeg et stort problem med. Det kan ske på mange måder, inkl. spoofing af websitet (en tjeneste som BitWarden sender ikke master-passwordet over SSL, men bliver websitet spoofed og taster du koden på et spoofed website, så har du et problem).

Måske overdriver jeg sikkerhedsrisikoen lidt, men jeg går helst uden om en password-manager hvor databasen tilgås via. SSL.

Dette forhindrer for øvrigt også at man er afhængig af en lokal salt. BitWarden salter fx ens master password med ens e-mailadresse, hvilket betyder at dit password altid bliver saltet med samme salt, selv hvis du skifter det. KeePass derimod benytter en tilfældig salt hver eneste gang en ny iteration af databasen gemmes.
Gravatar #37 - larsp
6. jan. 2023 08:28
larsp (31) skrev:
Vi har alle udviklet vores egne principper og teknikker til at holde styr på ting som passwords, som matcher vores risikotolerance. Jeg siger ikke at plugins generelt er udelukket mht. password.

Athinira (33) skrev:
Dette er så din - ja undskyld udtrykket - sølvpapirstilgang til browsing.
Jep. Det er nemlig min tilgang. Vi har alle vores sølvpapirshatte, nogle af dem giver sikkert mere mening end andre ;)
Athinira (34) skrev:
Jeg benytter 2 forskellige databasefiler til KeePass, en til über-sikre passwords som jeg ikke altid har åben (tænk krypteringsnøgler mm.), og en til almindelige passwords.
Hmm... Den ene keepass database er ikke sikker nok til visse hemmeligheder? Pudsigt ;) Når det kommer til stykket tænker vi nok ikke så forskelligt igen.

Jeg har ikke et (decideret) vandetta mod plugins. Der er mange situationer hvor plugins er geniale. Men oh, boy, hvor kan det også gå galt. Jeg har selv brændt fingrene på at lave et program pluginbaseret i min udviklerkarriere, og jeg har set så mange gange hvordan gode programmer bliver bøvlede og buggy efter det besluttes at næste version af programmet skal have 50% af funktionaliteten flyttet ud i plugins!

Det er sådan en ting mange unge og ambitiøse programmøre har i blodet. Alt skal modulariseres. Så meget som muligt. "Der er ingen vej uden om at lave et pluginsystem til vores lille simple applikation!" Og så ender den lille simple applikation som et gigantisk rod af server - client - pluginloader shit, der kræver en masse buggy plugins for at kunne det samme som den tidligere version kunne. Det er så typisk. Det gode er at de pågældende udviklere herefter har gennemlevet et vigtigt "coming-of-age" ritual for udviklere og herefter ser med stor skepsis på hele idéen med at pluginisere simple programmer ;)
Gravatar #38 - Athinira
6. jan. 2023 15:21
larsp (37) skrev:
Hmm... Den ene keepass database er ikke sikker nok til visse hemmeligheder? Pudsigt ;) Når det kommer til stykket tænker vi nok ikke så forskelligt igen.

Egentlig ikke.

For nu at give et eksempel på hvorfor jeg har den model, så har jeg også arbejdsrelaterede passwords/kontis i den alternative database jeg ikke altid har åben, samt mine forældres kontis (de er IT-analfabeter, så jeg hjælper dem med at holde styr på deres onlineliv).
Bliver min computer stjålet (eller tilgået uden min accept) mens denne database er åben og computeren ikke er låst, så kan det gå udover mit professionelle virke - dvs. at jeg skal informere min arbejdsgiver og potentielt også direkte involvere kunder hvis interesser jeg varetager. Det ville ligeledes også betyde at jeg skulle lave opsøgende arbejde i vores IT-systemer for at sikre at ingen af mine arbejdskontis eller andre oplysninger i databasen er blevet misbrugt. Det stiller mig med andre ord i et dårligt lys over for arbejdsgiver/kunder/forældre.

Alt dette sparer jeg mig selv for hvis databasen kun er åben når jeg bruger den. Der er intet "sølvpapirshat" over at have en alternativ passwordatabase til den slags som kun bliver åbnet når den skal bruges. Dermed kan jeg med god samvittighed sige til min arbejdsgiver at det ikke er noget problem at min computer blev tilgået, for adgangen til mine arbejdsrelaterede ting enten har været helt lukket, eller som minimum begrænset :-)

Sæt dette i kontrast til min normale database, hvor jeg kun har mine egne kontis i. Bliver min computer stjålet/tilgået mens den er åben, så er der også en del arbejde i at skifte alle mine passwords etc. deri for at sikre mig mod at mine konti bliver tilgået, ja. Men i det mindste har jeg dermed kun forpligtelser over for mig, og ingen forpligtelser over for andre. Dette er en del af essensen i at have den model.

Den anden del af essensen er at det giver øget beskyttelse mod fx ransagninger (ja, tilgang fra det offentlige er faktisk en bekymring). Se fx hende hvis computere og telefoner blev konfiskeret for nyligt uden en ransagningskendelse, fordi hun havde brugt det billede af en brændende dukke i en Facebookgruppe :-)

larsp (37) skrev:
Jeg har selv brændt fingrene på at lave et program pluginbaseret i min udviklerkarriere, og jeg har set så mange gange hvordan gode programmer bliver bøvlede og buggy efter det besluttes at næste version af programmet skal have 50% af funktionaliteten flyttet ud i plugins!

Her er vi enige. Plugins skal IKKE være en undskyldning for at lave et bare-bone program med minimal funktionalitet, og så bare overlade det til pluginudviklere at tilføje alt som mangler. Grundproduktet skal være solidt.

Plugins bør i min verden generelt benyttes være fordi et program kan have særlige use-cases som ligger uden for normal brug af programmet, og som opfylder særlige behov som visse brugere eller organisationer kan have, eller alternativt for at facilitere interaktioner med forskellige softwarepakker (fx forskellige browsere).

Speaking of, så er browsere netop et godt eksempel på at plugins giver mening. Det er jo ikke fordi at fx Chrome og Firefox ikke er solide applikationer i sig selv. Men browsere bruges så vidt og bredt og til så mange forskellige ting, at det simpelthen bare er umuligt at dække alle use-cases i kerneproduktet.
Gravatar #39 - Claus Jørgensen
6. jan. 2023 19:08
Gravatar #40 - arne_v
7. jan. 2023 00:32
#plugins

Det er meget banalt at sige at man bør bruge en plugin model når man har brug for det og ikke bruge en plugin model når man ikke har brug for det.

Men det er sandt.

Og hvis vi nu siger hvornår man har brug for den, så begynder det at have lidt substans:
- man har brug for en plugin mpdel hvis man ønsker at understøtte at andre (slutbrugere eller trediepart) kan lave udvidelser til ens program
- man har brug for en plugin model hvis man ønsker at slutbrugerne kan konfigurere hvilken funktionalitet de ønsker kørende i programmet

Hvis man skal have en plugin model er det så op til en at lave en god plugin model. Der er set en del dårlige plugin modeller. Både blandt hjemmelavede udgaver og blandt udgaver udviklet af store firmaer.

Jeg tror ikke at MS i bakspejlet er specielt glade for IE og ActiveX plugins. I Java verdenen har OSGI aldrig fået nogen stor success. I .NET verdenen har alle lykkeligt glemt alt om MAF.
Gravatar #41 - Athinira
8. jan. 2023 05:30
arne_v (40) skrev:
Jeg tror ikke at MS i bakspejlet er specielt glade for IE og ActiveX plugins. I Java verdenen har OSGI aldrig fået nogen stor success. I .NET verdenen har alle lykkeligt glemt alt om MAF.

Well, det var jo ikke fordi disse plugins ikke var brugbare. De blev jo benyttet. Men grunden til at de fortryder er jo nok mest pga. den manglende sikkerhed.

Udover mindsettet omkring IT-sikkerhed var meget anderledes dengang, og det grundlæggende ikke var noget man tænkte så designet af disse plugins, så var der også mange sikkerhedsteknologier som ikke var opfundet eller udbredt endnu på det tidspunkt. ActiveX udkom jo fx officielt i 1996, i en tid hvor sikkerhedsteknologier som fx DEP/W^X og ASLR ikke var opfundet endnu (ASLR blev for første gang implementeret i 2001 i Linux, W^X i 2003 i OpenBSD. Microsoft introducerede DEP i 2004 i Windows XP Service Pack 2).
Gravatar #42 - arne_v
8. jan. 2023 14:35
#41

Den manglende popularitet af OSGI og MAF har ikke noget med sikkerhed at gøre.

IE og ActiveX plugins er primært et sikkerhedsproblem.

Jeg vil kalde det et fejlagtigt koncept. Det er ikke smart at tillade web sider at loade ikke sandboxet native kode hvor det eneste man ved er at den udstiller nogle bestemte interfaces (IOleControl etc.).

ASLR og DEP løser ikke problemet. De er ikke relevante for de typiske custom ActiveX plugin. De er relvante for kode udførende sandbox plugins, men disse eksisterer (eksisterede) også til andre browsere med andre plugin teknologier (typisk via NPAPI) og er et selvstændigt problem. Og ActiveX modellen blev da også først lagt i graven længe efter at ASLR og DEP var introduceret.

Gravatar #43 - Athinira
9. jan. 2023 01:53
arne_v (42) skrev:
Jeg vil kalde det et fejlagtigt koncept. Det er ikke smart at tillade web sider at loade ikke sandboxet native kode hvor det eneste man ved er at den udstiller nogle bestemte interfaces (IOleControl etc.).

ASLR og DEP løser ikke problemet. De er ikke relevante for de typiske custom ActiveX plugin. De er relvante for kode udførende sandbox plugins, men disse eksisterer (eksisterede) også til andre browsere med andre plugin teknologier (typisk via NPAPI) og er et selvstændigt problem. Og ActiveX modellen blev da også først lagt i graven længe efter at ASLR og DEP var introduceret.

Jeg sagde ikke de var årsagen. Jeg gav dem bare som eksempler på teknologier der ikke var opfundet da ActiveX blev til.

Om de er relevante for de typiske ActiveX-plugins er jo ikke specielt relevant, da vores bekymring her er malware. Malware er vel næppe heller ikke dit typiske AX-plugin. Når det så er sagt, så er det som du nævner ekstremt kritisk at AX ikke blev kørt i en sandbox.

Omkring selve konceptet, så er det - ligesom mange andre pluginteknologier som kørte i browseren dengang, herunder Java og Flash - værd at huske på hvordan verden så ud dengang. Det var før HTML5, og websider dengang havde ikke specielt meget funktionalitet der var spændende som var understøttet i browsere, og browser extensions eksisterede så vidt jeg husker fx kun i Forefox og ikke i Microsofts browser. Java, AX og Flash blev jo opfundet for at opfylde et behov. Vil du påstå at behovet for udvidet browserfunktionalitet ift. hvad HTML tillod dengang ikke eksisterede? :-)
Gravatar #44 - arne_v
9. jan. 2023 16:14
Athinira (43) skrev:
arne_v (42) skrev:
Jeg vil kalde det et fejlagtigt koncept. Det er ikke smart at tillade web sider at loade ikke sandboxet native kode hvor det eneste man ved er at den udstiller nogle bestemte interfaces (IOleControl etc.).

ASLR og DEP løser ikke problemet. De er ikke relevante for de typiske custom ActiveX plugin. De er relvante for kode udførende sandbox plugins, men disse eksisterer (eksisterede) også til andre browsere med andre plugin teknologier (typisk via NPAPI) og er et selvstændigt problem. Og ActiveX modellen blev da også først lagt i graven længe efter at ASLR og DEP var introduceret.

Jeg sagde ikke de var årsagen. Jeg gav dem bare som eksempler på teknologier der ikke var opfundet da ActiveX blev til.


Der var mange teknologier som ikke eksisterede da ActiveX kom til.

Athinira (43) skrev:

Om de er relevante for de typiske ActiveX-plugins er jo ikke specielt relevant, da vores bekymring her er malware. Malware er vel næppe heller ikke dit typiske AX-plugin.


Et af problemerne med ActiveX plugins er at selv om de installeres med et fornuftigt formål så kan de misbruges i web sammenhæng. Det er ikke kun malware ActiveX plugins som er problemet.

Athinira (43) skrev:

Når det så er sagt, så er det som du nævner ekstremt kritisk at AX ikke blev kørt i en sandbox.


Ja. Og den primære grund til at browser ActiveX support og NPAPI support er væk idag.

Athinira (43) skrev:

Omkring selve konceptet, så er det - ligesom mange andre pluginteknologier som kørte i browseren dengang, herunder Java og Flash - værd at huske på hvordan verden så ud dengang.


Athinira (43) skrev:

Java, AX og Flash blev jo opfundet for at opfylde et behov.


Nu roder du tingene sammen.

ActiveX (og NPAPI) er plugin modeller.

Java applet player og Flash player er plugins.

Athinira (43) skrev:

Det var før HTML5, og websider dengang havde ikke specielt meget funktionalitet der var spændende som var understøttet i browsere, og browser extensions eksisterede så vidt jeg husker fx kun i Forefox og ikke i Microsofts browser.


Athinira (43) skrev:

Vil du påstå at behovet for udvidet browserfunktionalitet ift. hvad HTML tillod dengang ikke eksisterede? :-)


Der er faktisk ikke så meget som HTML 5 + CSS + JS kan som HTML 4 + CSS + JS ikke kan, men nogle er der (web socket, canvas etc.).

Den vigtigste drivkraft bag Java applets, Flash/Flex og SilverLight var nok snarere software folkets skepsis overfor HTML+CSS+JS som teknologi for store løsninger med meget kode.

Disse alternativer døde imidlertid med plugin modellers afskaffelse p.g.a. sikkerhedsproblemer (og manglende support fra Oracle, Adobe og Microsoft).

Men nye alternativer er skudt op siden. Google forsøgte med GWT men det fejlede. Microsoft forsøger nu med Blazor. Og der er også andre web assembly baserede løsninger som simrer. Lige nu er web 99.9% HTML+CSS+JS men det er ikke fordi man har opgivet at lede efter alternativer.


Gravatar #45 - Athinira
12. jan. 2023 13:56
sand (28) skrev:
Jeg bruger Bitwarden, som jeg skiftede til efter at have brugt Keypass et par år, men sync gennem Google Drive eller OneDrive eller min Synology Nas gik som regel galt før eller siden. Så jeg kiggede mig om efter et godt alternativ der IKKE hed LastPass...

Er godt tilfreds med Bitwarden og kan dele udvalgte data med ungerne og fruen.

Har fået prøvet bitwarden nærmere af nu (self-hosted på min NAS) hvor jeg har importeret mine passwords fra KeePass, og jeg må godt nok indrømme at brugerinterfacet ikke imponerer mig. Farvevalget er elendigt, og det er svært at danne sig et overblik over sine passwords hvis man har rigtigt mange. Alene det er nok til at få mig til at fravælge det.

Udover det er det dog et ganske fint program. God implementering, og jeg elsker hurtig-oplåsningsfunktionaliteten med PIN-kode samt understøttelsen af biometri (sidstenævnte dog kun i det normale program, ikke i browserplugin).
Gravatar #46 - larsp
12. jan. 2023 18:43
Athinira (45) skrev:
og jeg elsker hurtig-oplåsningsfunktionaliteten med PIN-kode samt understøttelsen af biometri (sidstenævnte dog kun i det normale program, ikke i browserplugin).
PIN koder til at låse PC mm. op. :) Endnu en ting jeg aldrig rigtig har forstået. Hvor meget hurtigere er det reelt at taste et par cifre (som en sidemand ret nemt kan lure af) sammenlignet med f.eks. et godt xkcd-style password https://xkcd.com/936/ ? Og som jeg forstår det, kræver en sikker pinkode implementation at man bruger TPM chippen, så master password kommer til at ligge i dens storage. Det er et godt eksempel på at lægge sit guldæg der hvor angribere først og fremmest forventer det ligger. Hvem ved om en given TPM chip bliver cracket en dag, og så er alle døre åbne. Glem det. Jeg er for gammeldags til den slags.

Og fingeraftryk. Tja, jeg ved godt at Claus igen vil sende joken med kryptonørden og svensknøglen, men der er altså forskellige niveauer af sikkerhed, og jeg ville ikke være tryg ved at beskyttelse en passwordvault med fingeraftryk alene. Det er så bare mig. Det er en low grade sikkerheds-barriere IMO, og den bygger på biometri hvilket er uheldigt. En angriber der stjæler en rygsæk med smartphone og laptop kan nemt replikere fingeraftrykket fra smartphonens skærm og derefter få adgang til password vault i laptoppen.
Gravatar #47 - larsp
12. jan. 2023 19:01
arne_v (40) skrev:
#plugins

Det er meget banalt at sige at man bør bruge en plugin model når man har brug for det og ikke bruge en plugin model når man ikke har brug for det.

Men det er sandt.

Og hvis vi nu siger hvornår man har brug for den, så begynder det at have lidt substans:
- man har brug for en plugin mpdel hvis man ønsker at understøtte at andre (slutbrugere eller trediepart) kan lave udvidelser til ens program
- man har brug for en plugin model hvis man ønsker at slutbrugerne kan konfigurere hvilken funktionalitet de ønsker kørende i programmet

Hvis man skal have en plugin model er det så op til en at lave en god plugin model.
Og det er nemmere sagt en gjort! Selv hvis der er god grund til at lave plugins i et scenarie kan det nemt gå galt. Et rigt plugininterface kræver at hovedprogrammet eksponerer en omsiggribende API hvis plugins skal være i stand til at kunne noget spændende. Her kommer så det første problem, og det er at man låser sig fast på gammel arkitektur og refaktorering ofte vil bryde plugin kompatibiltet.

Næste problem er så, at et sådant interface er som et åbent sår indtil hjertet af hovedprogrammet, og hvis der er et sikkerhedsaspekt, skal der altså være nogle robuste sikkerhedsmekanismer der forhindre al mulig tilfældig kode i at "være plugin". Dertil aspektet som nævnt at folk vil køre kode fra diverse ukendte pluginudviklere som ikke er en del af programmets core team.
Gravatar #48 - arne_v
12. jan. 2023 19:25
#47

Det er ikke helt nemt. Der har allerede været nævnt nogle af de mindre heldige.

Men jeg kan dog komme i tanke om en som ikke er en katastrofe. MySQL bruger en plugin model for database storage. Man kan vælge at bruge MyISAM, InnoDB eller noget mere eksotisk. Det er muligt at storage plugin udviklerne er utilfredse, men MySQL brugerne klager aldrig over det.
Gravatar #49 - DrHouseDK
18. jan. 2023 12:17
larsp (46) skrev:
PIN koder til at låse PC mm. op. :) Endnu en ting jeg aldrig rigtig har forstået.

Det er faktisk slet ikke så svært igen. En Azure AD eller AD joined maskine - her vil du give en væsentlig større adgang ved at nogen aflæser dit password fremfor din PIN. Nuvel, MFA vil da give noget, men langtfra alle virksomheder har MFA på plads. Derfor giver PIN mening - her får du udelukkende en lokal adgang afhængig af en enhed som du kan remote låse.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login