» »

YubiKey in 2nd Factor Authentication

YubiKey in 2nd Factor Authentication

mahoni ::

Zelim razumeti prednosti produkta YubiKey, ampak do sedaj se nisem sestavil za sefa nicesar, kar bi lahko opravicilo nakup taksnega kljucka za $50+. Vse kar je z njim mozno delati je mozno z aplikacijami na telefonu. Le te naj ne bi bile varne, zaradi MITM napadov, ampak do sedaj tega se nisem nikjer videl, da bi bil problem.

Cilj je stran od passwordov ter uvedba 2FA na vseh napravah oziroma na servisih kot je Microsoft 365 izdelki in podobno.

Bi bila uvedba smart card mogoce se najcenejsa? Problem je, ker ne vem kje, razen v windowsih, bi to lahko uporabljal.

Ima kdo kaksne izkusnje?

SeMiNeSanja ::

Vsaka od MFA rešitev ima svoje lastne fore, prednosti in slabosti.

Pri Yubikey mene malo bega, da se nekateri malo prehitro zapodijo in gredo praktično v eno-faktorsko avtentikacijo (samo še ključek).

Sploh pa imaš potem zabavne scenarije, ko se ključe pozabi, izgubi, se pokvarijo,...ali celo ukradejo. Za vse te scenarije moraš imeti na voljo ustrezno rešitev, ki pa ne sme biti preveč komplicirana, ker ti sicer vse skupaj hitro preraste preko glave.

Se je tudi treba zavedati, da nobena od MFA rešitev ne pokriva čisto vseh scenarijev. Tako npr. ne moreš z Yubikey zaščititi dostopa do VPN ali maila na mobitelu, saj nimaš kam vtakniti tisti kluček.

Glede na to, da pa ponekod celo onemogočijo vse USB porte, pa imaš hitro lahko še dodaten problem.

Na koncu se ti zna zgoditi, da boš v praksi uporabljal več različnih rešitev hkrati, da pokriješ vse potrebe.

Toda kaj bi šef šele rekel, če bi mu prišel z ponudbo za $6/user/mesec, kolikor stane DUO MFA v svoji 'najbolj popularni' varianti?
Pri tem se ti DUO najprej ponuja kot brezplačna varianta (do 10 uporabnikov). A ko začneš stvar enkrat malo bolj resno uporabljati in hočeš še to in ono opcijo, pa ne moreš več mimo plačljive verzije.

Microsoft tudi ponuja svoj MFA, ki krasno dela z Microsoft (pa mislim, da nima Windows mfa logon app-a?), a če hočeš sodelovati še z drugimi sistemi, si spet na doplačilih.

Torej koliko pa bi bil šef pripravljen investirati v MFA? In kaj vse želi z MFA pokriti?

Stvari so v določenih implementacijah lahko presneta nočna mora, predenj jih vzpostaviš.

Na koncu pa imaš še kup umazanih podrobnosti, ki jih vsak skuša po svoje prikriti. Npr: "Duo uses an event-based OTP (HOTP) rather than a time-based OTP (TOTP). This means that an OTP generated by Duo does not have a time restriction in which it must be used. For example, if you click on the Duo authenticator to generate OTPs in sequence, you can copy them and use them later (without time expiration)." No, pa zdaj pazi, da ti kdo ne pride blizu avtentikatorja...
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

Cr00k ::

Yubikey ima nfc, tako da na mobitelih prav super dela ;)

XS!D3 ::

SeMiNeSanja je izjavil:

Tako npr. ne moreš z Yubikey zaščititi dostopa do VPN ali maila na mobitelu, saj nimaš kam vtakniti tisti kluček.

Seveda ga imaš kam vtaknit, samo tapravo verzijo moreš kupit (USB-C/Lightning/NFC), vprašanje samo kateri protokoli so na ta način podprti na posamezni napravi.

Mavrik ::

mahoni je izjavil:



Ima kdo kaksne izkusnje?


Moje izkušnje imajo predvsem povezavo z managementom - če imaš telefon bodo ljudje prišli ki:

- Nimajo pametnega telefona
- Imajo prestar telefon
- Bodo izgubili telefon
- Nimajo zaščitenega telefona z geslom
- Imajo rootan telefon
- Uporabljajo telefon od hčerke

itd. itd.

V kolikor tvoja firma ne daje službenih telefonov zaposlenim, boš mel konstantno probleme z upravljanjem. S te perspektive so YubiKeyi precej bolj praktičn - veš katere imaš, veš kater firmware imajo in kako jih skonfigurirati.

Mi uporabljamo dve obliki: USB-A velike YubiKeye (ki so dobri za telefone in prenašanje) ter mikro USB yubikeye (USB-A ali C odvisno od naprave), ki so trajno vtaknjeni v napravo. Ta konfiguracija predstavlja najmanj problemov. Je pa res da moraš praktično vsakemu zaposlenemu dati dva ključka (enega za napravo in enega za rezervo/telefon).
The truth is rarely pure and never simple.

SeMiNeSanja ::

XS!D3 je izjavil:

SeMiNeSanja je izjavil:

Tako npr. ne moreš z Yubikey zaščititi dostopa do VPN ali maila na mobitelu, saj nimaš kam vtakniti tisti kluček.

Seveda ga imaš kam vtaknit, samo tapravo verzijo moreš kupit (USB-C/Lightning/NFC), vprašanje samo kateri protokoli so na ta način podprti na posamezni napravi.

Mogoče sem se slabo izrazil - tudi če bi imel možnost, da ga vtakneš v mobitel, si jaz nebi hotel uničiti vtičnico z dodatnim nepotrebnim priklapljanjem. Že z napajanjem si je marsikdo sčasoma uničil vtičnico, ne pa da boš neprestano še ključek noter tlačil.
NFC je kvazi opcija za tak primer, če ti ga telefon podpira.

Ampak resno - koliko jih poznaš, ki imajo na TELEFONU dostop do maila, VPN,... zaklenjen z Ubikey? Meni to že malo meji na mazohizem...
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

SeMiNeSanja ::

Mavrik je izjavil:


Moje izkušnje imajo predvsem povezavo z managementom - če imaš telefon bodo ljudje prišli ki:

- Nimajo pametnega telefona
- Imajo prestar telefon
- Bodo izgubili telefon
- Nimajo zaščitenega telefona z geslom
- Imajo rootan telefon
- Uporabljajo telefon od hčerke

itd. itd.

Za takšne so izdelali luštkane obeske za k ključem, ki ti generirajo OTP kodo namesto app-a na mobitelu ali računalniku.


Stanejo tam okoli 10-50€ odvisno od proizvajalca.

Feitian obeski so v večjih količinah kar ugodni.
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

Mavrik ::

SeMiNeSanja je izjavil:



Ampak resno - koliko jih poznaš, ki imajo na TELEFONU dostop do maila, VPN,... zaklenjen z Ubikey? Meni to že malo meji na mazohizem...


Več kot stotisoč ljudi na moji firmi in krepko več strank, ki uporabljajo isti sistem.
The truth is rarely pure and never simple.

SeMiNeSanja ::

Mavrik je izjavil:

SeMiNeSanja je izjavil:



Ampak resno - koliko jih poznaš, ki imajo na TELEFONU dostop do maila, VPN,... zaklenjen z Ubikey? Meni to že malo meji na mazohizem...


Več kot stotisoč ljudi na moji firmi in krepko več strank, ki uporabljajo isti sistem.

Ne vem, če se razumeva - govorim o odklepanju in povezovanju z mobilnega telefona.
Večinoma se mobilni telefon uporablja kot '2nd factor', ne pa da je zaklenjen z Yubikey-em ali čem drugim. Zato sem rekel, da bi bilo to sadomazo, če bi imel telefon zaklenjen z nekim tretjim mfa proizvodom (nima veze ali je to Yubikey ali kaj drugega!).

Tudi dostop do maila s telefonom zna biti problematičen, če ti push mail ne deluje, dokler nisi izvedel dodatne avtentikacije. Bi pozabil izvesti avtentikacijo, pa ti nebi vletel noben mail.... Potem se pa pregovarjaj zakaj ti uporabnik ni odgovoril...
Potem pa imaš še probleme z uporabniki, ki ti bodo rekli, da na njihov telefon že ne boš ničesar nameščal. Če že moraš, daj službenega....

Bistvo je, da nobena rešitev sama zase ni popolna - ne glede na to, koliko tisočev uporabnikov jo uporablja. Smo tudi že videl rešitve, ki so jih uporabljali tisoči - ki so bili globoko razočarani nad tem v kaj jih silijo.

Seveda pa imaš tudi zelo različne scenarije za kaj se katera zadeva uporablja. Marsikdo MFA zastavi precej 'ozkotirno', da pokrije samo tisto, kar smatra da je najbolj pereče. Čim greš na širši koncept, ti potem marsikje Yubikey ne bo več izpolnjeval zahtev.

Na splošno pa je meni bistveno bolj všeč sistem z push notifikacijo na mobitel, če se nekdo hoče prijaviti kot jaz. Tako sem še isti hip obveščen, da se nekaj dogaja in lahko ustrezno ukrepam.
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

SeMiNeSanja ::

......
V nasprotnem primeru, pa mi odobritev dostopa preko push notifikacije omogoča 'oddaljeno odklepanje', če bi moral nekomu dati dostop do sistema.

Kaj ti namreč pomaga, če si edini root admin na sistemu, greš na dopust, ključek pa odneseš s seboj?
Push sistem ti dejansko omogoči, da sodelavcu odkleneš sistem na daljavo. Podobno tudi OTP sistem, pač poveš sodelavcu trenutno kodo po telefonu.
Pri ključku si pa pečen, če nisi prej poskrbel za backup scenarij...
Tu je pa potem že vprašanje, kako boš preprečil, da ta backup nebi kdaj kdo zlorabil.

Skratka, nič ni popolno, idealno.
A po drugi strani je bolje imeti implementirano karkoli kakor nič.

Najbolje je začeti z enim računalnikom in 'eksperimentirati' kaj lahko počneš z izbrano rešitvijo in kaj ne, koliko je zahtevna za implementirat in vzdrževati, če si ji dorasel, ali ti dela sive lase.

Šele potem začni pridruževati še kakšnega kolega.
Če ti izbrani sistem ne ustreza, pa je še zmeraj čas, da zamenjaš na kaj drugega.
Dejstvo je namreč, da imajo določene rešitve zelo glasne 'navijače'. Greš in nabaviš zadevo...na koncu pa vidiš, da so te fino nasrali in si misliš j* tiste tisoče uporabnikov, če so bili nategnjeni tako kot jaz!

Pri tem je še toliko bolj zanimiva fama okoli tega Yubikey-a, kot da je edini tovrstni ključek. A samo zanj slišiš. Upravičeno? Dvomim. Precenjen? Morda?
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

XS!D3 ::

Da bi imel na ta način omejen dostop do mailov iz mobilnega telefona, se mi res ne zdi najbolj praktično, mislim da obstajajo druge dovolj varne in bolj praktične rešitve.

Zaenkrat z Yubikeyem eksperimentiram za lastne potrebe in ga uporabljam kot SmartCard (SigenCA), FIDO U2F za en kup storitev (to mi recimo deluje BP tudi na iOSu), (T/H)OTP za storitve, ki ne podpirajo U2F/FIDO, SSH ključe preko GPG agenta (vseeno se mi zdi boljše, da je ključ na HW modulu, pa čeprav ni kot 2nd factor), gpg ključe, in U2F za SSH, kjer je podprto. Če bi recimo SmartCard del ali SSH ključi delovali tudi na iOS bi mi bilo super za zadeve, do katerih rabim dostop samo izjemoma, takrat bi pač vtaknil YubiKey v telefon. Priznam, da še testiram različne primer uporabe, kjer bi zadeva imela nek benefit in bi bila še vedno dovolj praktična.

SeMiNeSanja ::

Meni se predvsem zdi noro, kakšni cenovni razponi so okoli teh ključkov in raznih mfa rešitev.

Na linku zgoraj (ki ga je nekaj popačilo) je sicer promocija, a vendarle - osnovni FIDO U2F ključek dobiš že za piškavih $1,5 - če vzameš 500 kosov. Količina sicer ni vabljiva za domačega uporabnika, bi pa lahko kakšen trgovec skočil na to ponudbo - stavim, da mu nebi obležali v skladišču.

Takšna cena pa je tudi že cena, pri kateri si lahko vsakdo privošči nakup ključka, pa čeprav samo za eksperimentiranje.
Pa tudi cena $10 pod katero ponujajo številne podobne ključke, se mi zdi še vedno presneto vabljiva za 'eksperimentiranje'. Če ti stvar na koncu ni všeč, pač nisi veliko izgubil.

Osebno me pri teh ključkih moti le to, da sem razmeroma pozabljiv človek in vem kako hitro znam doma pozabiti ključek, ki ni 'privezan na rep'. Presneto, zadnjič sem še očala doma pozabil...
Takšen pa nisem samo jaz. Ko pa imaš vsakodnevno opravka z lepo množico uporabnikov, ki ne morejo dostopati do računalnika ali storitev, ker so svoj ključek pozabili doma, se mi zadeva ne zdi več najbolj zabavna.

Tako da je za moje pojme ta del upravljanja eden pomembnejših, na katere moraš biti pozoren, ko se ukvarjaš z preučevanjem različnih mfa rešitev.
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

Mavrik ::

XS!D3 je izjavil:

Da bi imel na ta način omejen dostop do mailov iz mobilnega telefona, se mi res ne zdi najbolj praktično, mislim da obstajajo druge dovolj varne in bolj praktične rešitve. .


V praksi to deluje tako, da rabiš YubiKey samo pri dodajanju računa na telefon, zatem pa se ustvari t.i. Work Profile (Android) oz. namestijo službene aplikacije (iOS) in vklopijo obvezno uporabo PINa in kriptiranja naprave. Kasneje YubiKeya več ne rabiš, ob izgubi telefona pa se službeni profil preprosto na daljavo izbriše.
The truth is rarely pure and never simple.

SeMiNeSanja ::

Mavrik je izjavil:

XS!D3 je izjavil:

Da bi imel na ta način omejen dostop do mailov iz mobilnega telefona, se mi res ne zdi najbolj praktično, mislim da obstajajo druge dovolj varne in bolj praktične rešitve. .


V praksi to deluje tako, da rabiš YubiKey samo pri dodajanju računa na telefon, zatem pa se ustvari t.i. Work Profile (Android) oz. namestijo službene aplikacije (iOS) in vklopijo obvezno uporabo PINa in kriptiranja naprave. Kasneje YubiKeya več ne rabiš, ob izgubi telefona pa se službeni profil preprosto na daljavo izbriše.

Potem si pa že spet na istem, kot če si si shranil geslo... (kar itak vsi počnemo).

Razlika je le v toliko, da je tvoje geslo bistveno daljše in kompleksnejše od tistih, ki jih uporabljajo ostali smrtniki.
Istočasno pa je 'fiksno' in se ne spreminja. Nič ni 'One Time', je le dolgo in kompleksno. Kaj če ti potem nek malware ukrade to dolgo in kompleksno 'geslo'?

Če bi lahko v sliko dodal še device fingerprinting, da je token zapečen za določeni device in postane neuporaben čim ga skopiraš drugam, potem je stvar že spet čisto druga...

Ampak.... mogoče iščem dlako v jajcu?
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

Karen ::

Po mojem mnenju je nekako najboljši tradeoff praktičnosti in še vedno relativne varnosti 2ff v smislu username/pass/enkratna SMS koda. Moraš imeti username in password, pa še svoj GSM v posesti, ti pa ni treba nanj nič namestiti - sms pač pride in velja kolikor je nastavljeno, ni težav z namestitvijo kake aplikacije (edina težava je lahko "nimam GSM-a" ali "ne dam privatne GSM številke za ta namen" - če je GSM služben ne bi smelo biti težav. Kakšnih praktičnih množičnih zlorab tega sistema še nisem zasledil (četudi teoretično obstajajo), tudi banke ga na veliko uporabljajo, Sberbank recimo za login poleg certifikata na računalniku, pa za vsako transakcijo ki ni med hitrimi plačili... pa poceni je relativno, tako na oko če nimaš res veliko prometa si tam na max. 0,1 EUR na SMS za povprečno številko na EU nivoju. Servisov za SMS pošiljanje je pa polno, ala bivši Nexmo recimo. Če res rabiš da pride pa sprogramiraš še lastno rezervo... primarno pošlješ čez servis, pa aktiviraš gumb "nisem dobil SMS-a" po 30 sekundah pa pošlješ čez lasten lte modem na serverju recimo... pol pa že skoraj ni variante da ne bi dobil.
Glavna prednost je da uporabnik ne rabi nobenega novega HW-ja, GSM ima pa praktično vsak danes.

SeMiNeSanja ::

SMS kot 2fa je na splošno odsvetovan.

Naše banke se ga veselo poslužujejo, ker je zanje najcenejši, najlažji za implementirat in (še?) ni prepovedan (ter očitno zavarovalnice (še?) niso dvignile premije zaradi uporabe SMS).
Poleg tega je treba vedeti, da je EU določila Sept. 2019 kot skrajni rok, so morale banke uvesti neko obliko mfa. Ker SMS ni bil izrecno prepovedan, so se večinoma po poti najmanjšega odpora poslužili tega.

Če se morda še spomniš incidenta leta 2019 na Reddit? Takrat je bilo kar nekaj debate okoli (ne)varnosti SMS avtentikacije (primer: KrebsonSecurity - Reddit Breach Highlights Limits of SMS-Based Authentication).

Takrat je preko luže NIST malodane že izrekel splošni ban za SMS 2fa, pa se je potem nekoliko omehčal. Defacto pa je njegova uporaba odsvetovana.

Tudi če greš brskati čez različne strani ponudnikov MFA rešitev, ti bodo vsi odsvetovali SMS kot drugi faktor.

Zanimivo je stališče EBA (European Banking Authority), ki je v bistvu 'požegnalo' uporabo SMS MFA avtentikacije - pri tem pa se sklicevalo, da je SIM kartica tisti drugi faktor, ne pa samo SMS sporočilo.
Kakor pa danes vemo, lahko SMS prejmeš tudi na številko, katere osnova NI SIM kartica (razni VOIP servisi). S tem pa je v bistvu argumentacija EBA nična.

PCI DSS pa se lepo sklicuje na NIST &Co:
The intent of this document is to provide supplemental information.6Information provided here does not replace or supersede requirements in any PCI SSC Standard.February2017INFORMATION SUPPLEMENTGuidance for Multi-Factor AuthenticationUse of SMS for AuthenticationPCI DSS relies on industry standards--such as NIST, ISO, and ANSI--that cover all industries, not just the payments industry.While NIST currentlypermits theuseof SMS, they have advised that out-of-band authentication using SMS or voice has beendeprecated and may be removed from future releasesof their publication.


Torej pod črto.... na nebu so temni oblaki okoli SMS avtentikacije. Zadeva po sanašnjih merilih ne velja več za tako varno, kot si to želimo za MFA rešitve, katere vpeljujemo danes in naj bi nam služile za naslednje desetletje.

Banke so bile prisiljene 'nekaj' naresti na hitro. To, da so izbrale SMS, pa jih bo v prihodnosti znalo še koštat nekaj denarja. A tu so potem spet lobiji na delu, tako da ni nujno, da se karkoli spremeni prav kmalu (če so še NIST prepričali, da naj ne banna SMS...?).
Tako ali drugač pa je dejstvo, da se SMS avtentikaciji iztekajo dnevi.
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

Zgodovina sprememb…

SeMiNeSanja ::

Še ena stvar je tu....

današnje MFA rešitve gredo bolj v smeri 'zaščiti dostop do vsega', pri tem pa se nekatere tudi poslužujejo nekakšnih Single-Sign-On portalov. Tako enkrat potrdiš svojo identiteto, pa ti portal potem omogoča neposredni dostop do O365, Google Doc, LinkedIn, .... in seveda resursov podjetja - brez da bi se za to rabil dodatno avtenticirati in potrjevati.

Stvari so s pomočjo standardov postale povezane.

Če greš zdaj sam nekaj 'pacat' z zastarelim SMS, pa boš bolj ali manj obsojen na to, da boš ostal otoček v oceanu in se boš verjetno moral celo za vsak resurs podjetja posebej potrjevati preko SMS. Določene reči (Windows/Mac/Linux login?) pa najbrž sploh ne boš uspel implementirati...

Resda nekatere starejše MFA rešitve še vedno ponujajo SMS opcijo, medtem ko najnovejše to opcijo sploh niso več implementirale. Ugani zakaj?
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

XS!D3 ::

Mavrik je izjavil:


V praksi to deluje tako, da rabiš YubiKey samo pri dodajanju računa na telefon, zatem pa se ustvari t.i. Work Profile (Android) oz. namestijo službene aplikacije (iOS) in vklopijo obvezno uporabo PINa in kriptiranja naprave. Kasneje YubiKeya več ne rabiš, ob izgubi telefona pa se službeni profil preprosto na daljavo izbriše.

Tak solution je seveda potem že precej bolj praktičen.

SeMiNeSanja je izjavil:


Potem si pa že spet na istem, kot če si si shranil geslo... (kar itak vsi počnemo).

Razlika je le v toliko, da je tvoje geslo bistveno daljše in kompleksnejše od tistih, ki jih uporabljajo ostali smrtniki.
Istočasno pa je 'fiksno' in se ne spreminja. Nič ni 'One Time', je le dolgo in kompleksno. Kaj če ti potem nek malware ukrade to dolgo in kompleksno 'geslo'?

Če bi lahko v sliko dodal še device fingerprinting, da je token zapečen za določeni device in postane neuporaben čim ga skopiraš drugam, potem je stvar že spet čisto druga...

Ampak.... mogoče iščem dlako v jajcu?


Odvisno na kakšen način je zadeva izvedena. Je velika razlika med dolgim geslom in pa asimetričnimi ključi, sploh če se le te zgenerirajo na secure enclaveu v sami napravi in je nikoli ne zapustijo. Če recimo ključe za dostop do storitev zgeneriraš na HW modulu, ki ga potem odklepaš s PINom/face ID po možnosti z omejenim številom poskusov, z YubiKeyem ali na kak drug način pa samo v štartu avtoriziraš njihovo uporabo (spet z digitalnim podpisom), je to vseeno precej drugače kok kakršnokoli dolgo geslo, ki ga samo shraniš na napravi.

Ales ::

Če smo lih pri teh enklavah, se je kdo kaj igral s SSH ključi in Trusted Platform Module (TPM)?

XS!D3 ::

Jaz sem se na Macu s sekey in secretive, edino omejen si z ecdsa-sha2-nistp25. Pa na iPhoneu znotraj termiusa, ki ravno tako omogoča generiranje/hrambo SSH ključev znotraj secure enclavea.

SeMiNeSanja ::

Meni na Windows SSH ključe hrani (lahko tudi generira) tzv. "Reflection Key Agent". Nič TPM.

Za Android pa niti ne vem, kam jih je 'skril'....
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

Ales ::

Apple temu delu svoje strojne opreme reče Secure Enclave, ARM svojo imenuje TrustZone, potem sta tu še TPM (Trusted Platform Module) in preprostejši ekvivalent HSM (Hardware Security Module)...

Samsungov KNOX uporablja TrustZone, pri S20 seriji se nekaj hvalijo z nekim novim Secure Element, Google Pixel uporablja Titan M (ta spada pod HSM, če se ne motim). Huawei ima tudi nek Security Element (eSE/inSE).

Kratice na kratico na marketinški titanski podvig na novo kratico na kvadrat. :))

Odvisno torej kateri Android telefon imaš, ampak v nečem takem znajo biti tvoji zasebni ključi...

Moj laptop ima TPM 2 in ta vikend sem imel v planu raziskat tpm2-pkcs11 in tpm2-tools pa zgleda ne bo časa...

Point vseh teh Secure Enclave / TrustZone / BlaBlaBla / TPM rešitev je, da zasebni ključ nikoli ne pride ne v kratkotrajni in ne v trajni spomin naprave. Vse se dogaja znotraj tega ločenega HW/SW in dokler ta nima kake zijajoče luknje, je menda vse lepo in prav in vsi smo varni pred vesoljci.

Po drugi strani pa so programi kot je Reflection Key Agent, userspace zadeva, ne? Zasebni ključi na disku, v RAM-u, itd.. Katastrofa ;) :))

Kakorkoli, YubiKey in podobni so ekvivalent teh Secure Enclave / BlaBlaaa / TPM, a v obliki ločenega in lepo prenosnega HW/SW bundla...

Kar se userspace SW izvedbe tiče, je skoraj vseeno ali se povezuješ na YubiKey ali na Secure Enclave / BlaBlaaa / TPM. V principu ista zadeva, seveda pa je hudič v podrobnostih, kot vedno...

Edit: zmotu sem se pri kratici! :))

Zgodovina sprememb…

  • spremenil: Ales ()

SeMiNeSanja ::

Že res, da je fancy, če ključe nosiš na ločenem device-u / shraniš v safe, a hudič je vedno v (ne)združljivosti s številnimi aplikacijami, katere se uporablja.

Drugače pa ti ključki še niso tako stara zadeva - tam zunaj pa je gora legacy sistemov in programja, ki s temi rečmi niti pod razno ne ve kaj početi.

Pa tudi ljudje zadeve praktično ne poznajo, tako da tudi tisti, ki bi nujno potrebovali tovrstne "višje standarde" pogosto niti ne vedo, da bi jih rabili - kaj šele, kako jih implementirati.

Mogoče bi kdaj bilo zanimivo pripraviti kakšno delavnico na to vižo, da bi se lahko ljudje na lastne oči podučili. Drugače te zadeve ostajajo v zelo ozkih krogih nekih posvečenih 'izbrancev', ki stvari obvladajo in številnih drugih, ki jim je to bilo 'implementirano' - a ne vedo sploh za kaj se gre.

Roko na srce, smo do nedavnega tudi vsi imeli certifikate shranjene na diskih. Šele ko so nas banke prisilile, da smo certifikate lahko dobili le še na ključku, smo se potem pričeli spraševati, če bi tisti ključek lahko še za kaj drugega poslužil in potem začeli nanje nalagati tudi druge certifikate. Pa še to sem jezen, ker tako skrivajo tisti programček za nalaganje in brisanje certifikatov s ključka...

Pri SSH je tudi tako, da si kot 'navaden smrtnik' postaviš nek strežnik, pa te v bistvu nič ne sprašuje okoli kakšnih ključev. Niti ne veš kdaj so se generirali, niti kam so se shranili. Dejansko navadni smrtnik misli, da je za prijavo potreben zgolj user/pass, pozabi pa, da se je 'enkrat na začetku' zgodila neka izmenjava javnega ključa. Ker stvar 'deluje', se potem nihče ne ubada več s temi ključi.
...dokler ti ne pride nekdo, ki ti reče, da se pa nebi prijavljal z user/pass, ampak bi to rad storil z SSH ključem. No, potem pa imaš problem, ker te čaka brskanje, kaj za vraga moraš naresti, da bo to delovalo.

Kako malo ljudi se dejansko spozna na to področje, ti da vedeti že odziv na tako vprašanje.
V bistvu tudi jaz nimam kaj dosti pojma. Se pa vsaj malo praskam po glavi ob takem vprašanju in si mislim, da nebi bilo slabo malo več vedeti. A hudirja, čisto vse pa tudi ne moreš znat. Ko pa bom znal, bom pa verjetno znal približno tako, kot zna povprečni 'mežar' konfigurirat požarno pregrado - po poti najmanjšega odpora. Ravno toliko, da bo za 'proof of concept', ker to pač ni 'moje področje'. Vsaj danes ne.
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

Ales ::

Najbolj prav bi bilo, da se uporabniške aplikacije sploh ne povezujejo direktno na take ključe, kot je YubiKey. Komunikacija gre čez API na nivoju OS-a, kaj se potem dogaja v ozadju aplikacij načeloma ne bi smelo zanimati...

Npr. za sudo se nič ne spremeni, če se PAM v ozadju povezuje na YubiKey ali TrustZone ali TPM. Sudo tega sploh ne ve, niti ni potrebe, da bi vedel.

Težava je lahko na namenskih napravah, kjer OS ni posodobljiv ali pa se nihče ne bo ukvarjal s tem. Posledično se PAM na taki napravi ne bo povezal na YubiKey, četudi ga nekdo vstavi USB ali 5,25" disketno enoto, vseeno...

Tudi sama implementacija pogosto šepa, dokumentacija zna biti pomanjkljiva, API-ji so razdrobljeni na več koncev... Standardne IT težave... Tako da dejansko ni vedno lahko integrirati te zadeve.

Kako malo ljudi se dejansko spozna na to področje, ti da vedeti že odziv na tako vprašanje.
Pod vse to se lahko samo podpišem.

Zgodovina sprememb…

  • spremenil: Ales ()

MrStein ::

Glede SMS: ni ne prvič, ne zadnjič, da eni "stavijo" na (veliko) manj varno opcijo, ko je na voljo (veliko) bolj varna.

Teorija zarote? Nesposobnost? Kdo bi vedel...
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Karen ::

@Stein:
po mojem nič od tega. Prej bi rekel tradeoff. Roko na srce SMS je za marsikaj res najbolj priročen - ne potrebuješ posenega HW-ja (razen tistega ki ga imaš), dela povsod, uporabnik je lahko debil z diplomo pa ga bo znal prebrat in vpisat. Če so omejimo na 2FF avtentifikacijo aplikacije na Androidu recimo je že precej bolj kompleksna za userja - mora namestit Authenticator, mora ga skonfigurirat, če izgubi/zamenja telefon je spet ponovi vajo (isto recimo m-žeton pri bančni aplikaciji na mobilcu, čeprav lažje; Aplikacijo za banko imaš gor, konfiguracije za m-žeton je malo oz. je ni)... pri SMS-u teh kolobocij ni: ista cifra, drug mobitel. Nekje je pač meja ko je praktičnost pred varnostjo.
Ne vem če imaš kaj izkušenj na helpdesku ampak pri 1000 userjih z Authentikatorjem ti lahko povem da lahko kar enega na helpdesku samo za to zaposliš, pa ne enega, za 24/7 support štiri.
Običajno se glede kakšna je realna verjetnost (masovne) zlorabe in škode: če so primeri res izjemoma, recimo 1 primer na milijon s potencialno škodo 10.000 EUR, ne boš šel implementirat rešitve ki bo sicer naredila verjetnost 1 proti 100 MIO, hkrati pa bo 2 MIO ljudi vsakič porabilo pol minute več da se logira. To potem nanese 1 MIO minut na login vsakega, krat logini, dejansko se to meri v urah ko bi lahko recimo zaposleni efektivno delal pa se logira namesto tega.
Vem da je debata tehnična, ampak na koncu je potrebno pogledati tudi praktičnost popolne varnosti.
p.s.: ni bilo mišljeno da se ne strinjam s tabo - bolj reciva temu drugačen pogled na problem oz. kako je potrebno tudi s stroškovnega/praktičnega vidika gledat na to. Eno je če implementacijo delaš na varnostni službi, drugo pa če pokrivaš neko podjetje z relativno nizkimi tveganji - vsi sicer trdijo da imajo know-how ki je res kritičen, ampak roko na srce je takih podjetij relativno malo.

Zgodovina sprememb…

  • spremenil: Karen ()

M.B. ::

@Stein: Tudi ni logično zakaj je NKBM šla iz RSA ključkov kot 2FA na SMS. Ključki so čisto fajn delali. Sedaj pa prah nabirajo doma, in ker banka mora met mojo telefonsko da mi lahko SMS pošlje mi pošilja še SMSe kako je najboljša banka v sloveniji pa kliče za nek nov paket Odlična uporabniška izkušnja. Geslo za prijavo je pa lahko sestavljeno samo iz številk. :O (verjetno posledica tega ker je prej bila to koda iz ključka). Zanimivo pa je da delavska hranilnica ima samo 4 števke kodo v SMSu NKBM pa 8.
Everyone started out as a newbie.
Sadly only a handful ever progress past that point.

SeMiNeSanja ::

Karen je izjavil:

@Stein:
po mojem nič od tega. Prej bi rekel tradeoff. Roko na srce SMS je za marsikaj res najbolj priročen - ne potrebuješ posenega HW-ja (razen tistega ki ga imaš), dela povsod, uporabnik je lahko debil z diplomo pa ga bo znal prebrat in vpisat. Če so omejimo na 2FF avtentifikacijo aplikacije na Androidu recimo je že precej bolj kompleksna za userja - mora namestit Authenticator, mora ga skonfigurirat, če izgubi/zamenja telefon je spet ponovi vajo (isto recimo m-žeton pri bančni aplikaciji na mobilcu, čeprav lažje; Aplikacijo za banko imaš gor, konfiguracije za m-žeton je malo oz. je ni)... pri SMS-u teh kolobocij ni: ista cifra, drug mobitel. Nekje je pač meja ko je praktičnost pred varnostjo.
Ne vem če imaš kaj izkušenj na helpdesku ampak pri 1000 userjih z Authentikatorjem ti lahko povem da lahko kar enega na helpdesku samo za to zaposliš, pa ne enega, za 24/7 support štiri.
Običajno se glede kakšna je realna verjetnost (masovne) zlorabe in škode: če so primeri res izjemoma, recimo 1 primer na milijon s potencialno škodo 10.000 EUR, ne boš šel implementirat rešitve ki bo sicer naredila verjetnost 1 proti 100 MIO, hkrati pa bo 2 MIO ljudi vsakič porabilo pol minute več da se logira. To potem nanese 1 MIO minut na login vsakega, krat logini, dejansko se to meri v urah ko bi lahko recimo zaposleni efektivno delal pa se logira namesto tega.
Vem da je debata tehnična, ampak na koncu je potrebno pogledati tudi praktičnost popolne varnosti.
p.s.: ni bilo mišljeno da se ne strinjam s tabo - bolj reciva temu drugačen pogled na problem oz. kako je potrebno tudi s stroškovnega/praktičnega vidika gledat na to. Eno je če implementacijo delaš na varnostni službi, drugo pa če pokrivaš neko podjetje z relativno nizkimi tveganji - vsi sicer trdijo da imajo know-how ki je res kritičen, ampak roko na srce je takih podjetij relativno malo.


Kot sem rekel... ker je bilo v določenem trenutku dopustno, najbolj enostavno in najceneje preiti na SMS 2fa.
Enostavnost se ne bo nikoli spremenila. Lahko pa se spremenita druga dva faktorja, odvisno od tega, kdo 'politično' sedi na daljšem vzvodu. Sama tehnika je tu jasna, a ni bistvena. Vprašanje je bolj ekonomsko-politično, kot npr. da bi zavarovalnice zavohale, da lahko iztržijo še kakšen cekin na račun tega, da je sms odsvetovana varianta, pa bi na ta račun pričele dvigati zavarovalne premije. V večni tekmi za doseganje višjih dobičkov to ni tako za lase privlečena opcija.

Lahko pa se zgodita še kakšna dva odmevna primea vdorov in odtekanja osebnih podatkov zaradi uhajanja SMS 'faktorjev', pa se politika odloči, da je treba obdobje toleriranja SMS 2fa enostavno zaključiti.

Za enkrat še nismo tu.
Kljub temu, če stvari na novo vpeljuješ, se je dobro zavedati, da SMS ni več priporočen. Ali se boš kljub temu odločil zanj, pa je na tebi.
Tako nekako, kot se odločaš za dizel pogon, čeprav veš, da boš v bodoče lahko računal na določene težave.

Kljub vsemu, pa se mi zdi, da tudi SMS 2fa ne reši vseh problemov helpdeska. Ljudje tudi pri sms avtentikaciji pozabljajo telefone doma, telefoni se izgubijo, pokvarijo, jih ukradejo. Nič prav veliko manj težav iz teh naslovov za helpdesk, kot če bi uporabljal TOTP generator app.
Sem pa nekoliko sumničav, da ima Google prav veliko podpornikov, ki se ukvarjajo z podporo mfa uporabnikom?

Pa to pri VELIKIH firmah z 1000+ uporabniki niti ni tak problem, ker vsaj imajo helpdesk. Kaj pa mikro in male firme? Tam od 5-50 uporabnikov...z enim ali celo nobenim 'računalnikarjem'? No, tukaj potem stvari postanejo zares 'zabavne'. Kot so nekoč rekli 'lahko je srat na polno rit'. Če imaš malo armado informtikov + helpdesk, boš že nekak preživel dan. Toda kaj, če tega 'luksuza' nimaš?
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

XS!D3 ::

SeMiNeSanja je izjavil:

Že res, da je fancy, če ključe nosiš na ločenem device-u / shraniš v safe, a hudič je vedno v (ne)združljivosti s številnimi aplikacijami, katere se uporablja.

Drugače pa ti ključki še niso tako stara zadeva - tam zunaj pa je gora legacy sistemov in programja, ki s temi rečmi niti pod razno ne ve kaj početi.

Pa tudi ljudje zadeve praktično ne poznajo, tako da tudi tisti, ki bi nujno potrebovali tovrstne "višje standarde" pogosto niti ne vedo, da bi jih rabili - kaj šele, kako jih implementirati.

Mogoče bi kdaj bilo zanimivo pripraviti kakšno delavnico na to vižo, da bi se lahko ljudje na lastne oči podučili. Drugače te zadeve ostajajo v zelo ozkih krogih nekih posvečenih 'izbrancev', ki stvari obvladajo in številnih drugih, ki jim je to bilo 'implementirano' - a ne vedo sploh za kaj se gre.

Roko na srce, smo do nedavnega tudi vsi imeli certifikate shranjene na diskih. Šele ko so nas banke prisilile, da smo certifikate lahko dobili le še na ključku, smo se potem pričeli spraševati, če bi tisti ključek lahko še za kaj drugega poslužil in potem začeli nanje nalagati tudi druge certifikate. Pa še to sem jezen, ker tako skrivajo tisti programček za nalaganje in brisanje certifikatov s ključka...

Pri SSH je tudi tako, da si kot 'navaden smrtnik' postaviš nek strežnik, pa te v bistvu nič ne sprašuje okoli kakšnih ključev. Niti ne veš kdaj so se generirali, niti kam so se shranili. Dejansko navadni smrtnik misli, da je za prijavo potreben zgolj user/pass, pozabi pa, da se je 'enkrat na začetku' zgodila neka izmenjava javnega ključa. Ker stvar 'deluje', se potem nihče ne ubada več s temi ključi.
...dokler ti ne pride nekdo, ki ti reče, da se pa nebi prijavljal z user/pass, ampak bi to rad storil z SSH ključem. No, potem pa imaš problem, ker te čaka brskanje, kaj za vraga moraš naresti, da bo to delovalo.

Kako malo ljudi se dejansko spozna na to področje, ti da vedeti že odziv na tako vprašanje.
V bistvu tudi jaz nimam kaj dosti pojma. Se pa vsaj malo praskam po glavi ob takem vprašanju in si mislim, da nebi bilo slabo malo več vedeti. A hudirja, čisto vse pa tudi ne moreš znat. Ko pa bom znal, bom pa verjetno znal približno tako, kot zna povprečni 'mežar' konfigurirat požarno pregrado - po poti najmanjšega odpora. Ravno toliko, da bo za 'proof of concept', ker to pač ni 'moje področje'. Vsaj danes ne.


Ne gre za to, da je fancy, ampak da je vse skupaj na ločenem HW modulu, ki opravlja vse (asimetrične) crypto operacije (generiranje ključev, podpisovanje, šifriranje, dešifriranje,...) in načeloma nimaš nikoli direktnega dostopa do zasebnega ključa tudi če imaš dostop do same naprave (lahko kvečemu v tistem trenutku uporabiš ključ za podpis/šifriranje/dešifriranje, če imaš PIN/prstni odtis/faco/geslo/se nekdo fizično dotakne ključka ali karkoli je pač zahtevano za uporab privatnega ključa). To ni nič novega, recimo t.i. pametne kartice obstajajo že zelo dolgo in se uporabljo za vse živo od avtentikacije telefonov v mobilna omrežja (SIM kartice), bačnih kartic, do kartic za kontrolo dostopa televizijskih kanalov (ala Conax), certifikate/ključe za dostop do spletnih bank, itd..... Tudi HSM na strežniški strani se že nekaj časa uporabljajo za specifične varnostno kritične sisteme. Počasi pa je vedno več teh "modulov" tudi v consumer napravah (ala TPMji, Apple T2,...), npr. v tablicah/telefonih/laptopih, kjer se recimo hranijo ključi za full disk encryption in podobne zadeve (Apple recimo od iPhone 5s dalje, v Macih pa pomoje zadnji 2 leti recimo).

Tudi za druge primere uporabe, če zadeve uporabljaš čez neke stadardne APIje, je popolnoma vseeno ali je zadaj HW modul ali pa neka SW implementacija. Recimo moji SSH ključi, ki so na YubiKeyu in jih uporabljam preko gpg-agenta, so za vse aplikacije vidni/uporabni enako kot običjni ključi na disku preko ssh-agenta, s to razliko, da privatnega ključa pač ne moreš dobit dol, tudi če imaš dostop do mašine (poleg tega se moraš za uporabo SSH ključa med drugim fizično dotaknit YubiKey ključka). Tvoj Reflection SSH agent, pa kolikor vem, hrani privatne ključe čisto običajno na trdem disku, kjer ga lahko brez problema skopiraš dol, če imaš dostop do mašine (npr. malware). Tudi če imaš nastavljeno geslo je, ko ga enkrat odklenješ, če drugega ne, na voljo v plain text obliki nekje v RAMu.

Druga stvar so seveda novi protokoli ala U2F/FIDO, ki še niso podprti povsod, ampak počasi prihajajo v različen aplikacije (večina novejših brskalnikov ima že podpora, pa kar nekaj spletnih servisov, potem novejši OpenSSH strežniki/klienti v ta namen podpirajo nov tip ključa ecdsa-sk, itd.). Tehnološko je tole mnogo bolje kot običajen OTP, kaj šele če da OTP dobiš na SMS, kjer imaš še dodatne vektorje napada.

Kar se pa samega SSHja tiče, če dovoljujeješ uporabo user/pass za avtentikacije, za moje pojme že v štartu zadeve nimaš skonfigurirane najbol varno.

M.B. ::

Ironično je tudi da banke zahtevajo hranjenje certifikatov na pametnih ključkih FURS pa ne podpira podpisovanje dokumentov če so certifikati shranjeni na pametnem ključu na Linuxu. Na srečo to sedaj ni več problem, ker podpisovanje poteka na drug način, ampak sam si ne upam prestavit certifikat na pameten ključ, ker ne vem kdaj bo kateri od x državnih servisov spet potreboval kakšno podpisovanje in ne bo podpiral certifikata na pametnem ključu.
Everyone started out as a newbie.
Sadly only a handful ever progress past that point.

SeMiNeSanja ::

XS!D3 je izjavil:

TLDR


Vse kar si napisal drži, ampak jaz sem govoril čisto o nečem drugem.

Kot npr. če nekdo namesti linux (ali katerikoli drugi) strežnik in potem uporablja ssh za dostop. Kaj je default? User /Pass avtentikacija. Karkoli drugega je 'nestandardno' ali da rečemo 'nadstandard'.

Če bi zdaj šel čez vse ssh strežnike - koliko jih uporablja še karkoli drugega kot user/pass?

Pa tudi proizvajalci rešitev pacajo. Imam en komercialni SSH server, ki podpira avtentikacijo s pomočjo X.509 certifikatov. Saj lepo in prav - a kaj, ko ta cert ni uporabljen kot 2. faktor, temveč direktno kot prvi, brez dodatnega preverjanja user/pass ali česarkoli drugega...

Potem pa se od uporabnikov pričakuje čudeže?
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

XS!D3 ::

SeMiNeSanja je izjavil:


Če bi zdaj šel čez vse ssh strežnike - koliko jih uporablja še karkoli drugega kot user/pass?

Praktično vsi, ki vejo, kaj delajo :) Auth z user/pass pa eksplicitno izklopljen z razlogom. Vsaj na sistemih s katerimi delam....

Uporaba default gesel in konfiguracij nikoli ni bila ravno najbol pametna ideja, tako da to, kaj dobiš by default nastavljeno, ni glih neko merilo.

SeMiNeSanja je izjavil:


Pa tudi proizvajalci rešitev pacajo. Imam en komercialni SSH server, ki podpira avtentikacijo s pomočjo X.509 certifikatov. Saj lepo in prav - a kaj, ko ta cert ni uporabljen kot 2. faktor, temveč direktno kot prvi, brez dodatnega preverjanja user/pass ali česarkoli drugega...


Kot sem že prej omenil, je tudi kot one and only auth (brez 2nd faktorja) uporaba asimetričnih ključev, še vedno mnogo bolj varna, kot pa user/pass kot edini auth (če so ti shranjeni na namenskem crypto hw in dodatno zaščiteni z geslom/PINom/... pa sploh). Ne rezumem, za kaj bi na vsak način zraven tlačil nek username/pass, to je sploh pri SSHju za moje pojme obsolete. Če že, uporabiš pač SSH ključ in še kak dodaten faktor (OTP, notification v mobile app, itd) ozirom ključ tipa ecdsa-sk/ed25519-sk, ki je kombinacija lokalnega ključa in tokena s pomočjo FIDO2 ključka.

Zgodovina sprememb…

  • spremenil: XS!D3 ()

SeMiNeSanja ::

XS!D3 je izjavil:

SeMiNeSanja je izjavil:


Če bi zdaj šel čez vse ssh strežnike - koliko jih uporablja še karkoli drugega kot user/pass?

Praktično vsi, ki vejo, kaj delajo :) Vsaj na sistemih s katerimi delam....

Ti kar jaz lepo povem, da manj kot 1% SSH strežnikov uporablja karkoli drugega kot user/pass.

Ne vem, v katerem vrtičku ti živiš....

Sicer ne vem, ali se pogovarjamo o dostopu za admine in kakšne priviligirane uporabnike, ali imaš v mislih tudi dostope do 'javnih' storitev s stotinami in tisoči uporabnikov.

Tisti 1%, ki sem ga navedel velja za admin/root dostope. Ali to zdaj pomeni, da povprečni admin nima pojma kaj dela...o tem naj kdo drug presoja.

Je pa tudi malo absurdno, da se potem npr. za SSH stvar 'zakomplicira' do skrajnosti, potem pa najdeš na istem sistemu kakšen proces, ki čisto lepo uporablja zgolj user/pass za avtentikacijo in to po možnosti še v cleartext varianti (FTP, TELNET, POP3,...). Noja... itak je bilo govora o onih, ki ne vedo... A kaj huduča, ko jih je kot peska v sahari!
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

SeMiNeSanja ::

XS!D3 je izjavil:


SeMiNeSanja je izjavil:


Pa tudi proizvajalci rešitev pacajo. Imam en komercialni SSH server, ki podpira avtentikacijo s pomočjo X.509 certifikatov. Saj lepo in prav - a kaj, ko ta cert ni uporabljen kot 2. faktor, temveč direktno kot prvi, brez dodatnega preverjanja user/pass ali česarkoli drugega...


Kot sem že prej omenil, je tudi kot one and only auth (brez 2nd faktorja) uporaba asimetričnih ključev, še vedno mnogo bolj varna, kot pa user/pass kot edini auth (če so ti shranjeni na namenskem crypto hw in dodatno zaščiteni z geslom/PINom/... pa sploh). Ne rezumem, za kaj bi na vsak način zraven tlačil nek username/pass, to je sploh pri SSHju za moje pojme obsolete. Če že, uporabiš pač SSH ključ in še kak dodaten faktor (OTP, notification v mobile app, itd) ozirom ključ tipa ecdsa-sk/ed25519-sk, ki je kombinacija lokalnega ključa in tokena s pomočjo FIDO2 ključka.

No, da ne boš prehitro hvalil, da je 'vsaka uporaba asym ključev bolj varna' - stvar hudo zavisi od implementacije.

Primer ki sem ga navajal, je uporabniške certifikate uporabil le toliko, da je iz njih prebral enega od uporabnikovih podatkov, običajno email naslov.

To pomeni, če uspeš pridobiti veljaven cert (nisem preverjal, če bi 'požrl' tudi self-signed cert), ki ima enak mail naslov zapisan v certu, kot ga ima originalni uporabnik, se brez težave direktno prijaviš v njegov account.

Se še čudiš, zakaj me je minilo navdušenje nad to implemntacijo?
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)

M.B. ::

Vem da Amazon ne omogoča user/pass prijave po defaultu. Ali ima generiran ključ, ali mu pa ti poveš kakšen ključ naj uporabi. (uplodaš public part). Glede na to da je AWS nekje največji igralec bi rekel da je to kr standard.
Everyone started out as a newbie.
Sadly only a handful ever progress past that point.

techfreak :) ::

Podobno je tudi na GCE. Vecina cloud ponudnikov ti vsaj priporoca uporabo SSH kljuca, ce ti ne kar prepreci uporabe imena/gesla (npr. AWS, GCE.)

Samael ::

Oživljam temo z re-postom iz teme "dobrih cen", ker se mi zdi, da bi znalo komu prav pridit.

Samael je izjavil:

Ne vem, če je kdo že omenil, ampak CloudFlare ponuja kupon za YubiKey 5 NFC / YubiKey 5C NFC (ta zadeva na mimovrste stane cca 65 eur / kos) po cca 10 do 12 eur / kos.
Sprva je bil limit max 10 ključkov, zdaj so štirje, kar je še vedno več kot dovolj za osebno rabo. Pošljejo s Švedske, najcenejša poštnina do nas je 5 eur.
Na CF moraš imeti vsaj en zone (dodaj dns za eno domeno al nekaj, če nimaš), da ti na zahtevek v dnevu, dveh al nekaj ... pošljejo kodo.

Za enega YubiKey 5C NFC in dveh YubiKey 5 NFC sem dal vsega skupaj s pošnino in DDV-jem vred €45.41

Več o tem tu:

https://blog.cloudflare.com/making-phis...
https://www.cloudflare.com/en-gb/produc...
Samael != Samuel

Matija82 ::

Oživljam, ker imam en starejši YubiKey Standard, ki ga ne uporabljam (kupljen pač kot noviteta in je ostal v predalu 4 leta).
https://support.yubico.com/hc/en-us/art...


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Apple, Google in Microsoft standardizirajo podporo vpisovanju brez gesla (strani: 1 2 )

Oddelek: Novice / Ostala programska oprema
6411023 (7351) Mr.B
»

Novi standardi informacijske varnosti v bančništvu (strani: 1 2 )

Oddelek: Novice / Varnost
9719617 (12532) MrStein
»

Naprodaj pol milijona Zoomovih uporabniških računov

Oddelek: Novice / Varnost
408629 (5222) MrStein
»

Security key

Oddelek: Strojna oprema
101876 (1513) Qushaak
»

NFC logiranje v različne accounte

Oddelek: Informacijska varnost
102128 (1682) MojoRisin

Več podobnih tem