Novi standardi informacijske varnosti v bančništvu

Cowboy6 je 3. sep 2020 ob 09:29 izjavil:

_Sajmon_ je 3. sep 2020 ob 09:06 izjavil:

Vsi, ki pljuvate po tej kao varnostni luknji: kaj pa bi pa za vas bilj najbolj sprejemljiv način prijave v elektronsko banko? Ne nujno najbolj varen, ampak tak, ki bi bilj najboljši kompromis enostavnosti in varnosti?

IMHO, uporaba certifikata in kompleksnega gesla je sprejemljiv način. Da se temu doda še 2FA je dovolj varen način.

certifikat in geslo sta že dva faktorja in to precej močna (pri geslu je seveda odvisno od politike)

Spura je 3. sep 2020 ob 09:52 izjavil:

MrStein je 2. sep 2020 ob 21:43 izjavil:

NLB ima še vedno omejitev, da v geslu ne sme biti "posebnih" znakov?

Hja, varnost "po naše".

Ali website uporablja CP-1250 namesto unicode (to je pri nasih mojstrih kar pogosto, sploh uni ki delajo v .NETu) ali pa v bazi shranjujejo clear-text gesla in nimajo baze na unicode nastavljene. To da imajo bazo na CP-1250 nastavljeno je pa kar 100% verjetnost.

Kaj ima to veze s tem, da v geslu ne smejo biti naslednji ASCII znaki: , . - / ! ?

joze67 je 3. sep 2020 ob 10:14 izjavil:

MrStein je 2. sep 2020 ob 22:14 izjavil:

OK, vdri v mojo.
Aja ne moreš. Ker nimaš mojega telefona. Pa tudi, če bi ga imel, ne bi mogel.

Na www.spletna-banka.si pa lahko greš kadarkoli.

To je razlika.

Res, ampak se moraš še zanašati na operaterja, da ni preveč prijazen in ne izda novega SIM-a kar na osnovi telefonskega klica in kakega "osebnega" podatka.

Ne rabim. Lahko ti dam original SIM. Pa še PIN zraven. Tako za SIM, kot za bančno aplikacijo. Pa še vedno ne boš mogel.

Smo zdaj to razčistili?

YubiKey podpira x.509 certifikate, podobno kot Gemalto in podobni USB kljuci. Mogoce se tudi to spreminja, ampak poslovni uporabniki so vcasih dobivali pametno kartico in bralnik, oz. USB kljucek s certifikatom.

Ne vem, zakaj se iz ene ušive avtentikacije dela takšno znanost.

Mathai predlaga Ubikey. Meni ta metoda ni všeč, ker bi se jo z 99,9% verjetnostjo uporabilo kot enofaktorsko avtentikacijo - ukradeš ključ in lahko neovirano dostopaš do accounta, ne rabiš več ne userja, niti geslo, saj imaš ključek.

Težava je v tem, da se tudi Yubico sam promovira, da predstavlja konec za kakršnakoli gesla (ravno danes bral članek njihovega product managerja "Warum FIDO2 das Ende des Passworts bedeutet"), mene pa zmrazi, če pomislim, da si rabi nekdo samo za nekaj sekund 'sposoditi' ključek, pa jaz o tem ne bom nič vedel, ne prej, ne kasneje.
Ne vem zakaj se pri izgubi/kraji ključkov vedno predpostavlja, da bo ključek našel/ukradel nek popolni neznanec, ki ne bo vedel za katere sisteme/accounte ta ključek uporabljaš. Kaj pa če ga ukrade 'insider'? Npr. nezadovoljna delavka v računovodstvu, medtem ko je direktor/računovodja skočil na WC? Sodelavka bo točno vedela kako 'uporabiti' tisti ključek....

Potem mi je že bolj pri srcu kakšen 2fa na osnovi push notifikacije, ki mi na telefonu 'zateži', čim je nekdo vtipkal moj user/pass. Ni važno kje na svetu sem - če imam internetni dostop, me bo opozorilo, da nekdo nekaj poskuša.

Sem nekoč že prilepil video, kako te zadeve lahko izgledajo v bančništvu (se uporablja že leta v Braziliji)



Pri tem v videjih ni povedano, da se pri inicializaciji push storitve shrani 'prstni odtis' telefona, tako da odpade kakršnakoli možnost kopiranja na drug telefon.

V takem primeru rešitve moraš potem vedeti:
1.) username
2.) geslo ali pin bančnega accounta / kreditne kartice
3.) imeti v posesti telefon lastnika accounta
4.) 'znati' odkleniti telefon (pin, pattern, biometr. odklep)
in opcijsko...
5.) še dodaten pin za odklep push potrditve

Pretiravanje?

No, ker se nekaterim zdijo takšne 'klasične' metode pretirane, so se lotili ustvarjati 'moderne' metode avtentikacije, katere temeljijo na analitiki obnašanja uporabnika.
Tovrstnih rešitev obstaja tudi že kar nekaj (BioCatch, Forter, NUData-Mastercard,..), temeljijo pa na tem, da za osnovni dostop uporabiš nekaj enostavnega na nivoju teh 6-mestnih pin-ov nad katerimi se v tej temi zgražamo.
Od tistega osnovnega dostopa dalje, pa se spremlja, katere menije klikaš, kako hitro premikaš miš, kako hitro tipkaš, itd. itd. in se to ves čas beleži oz. primerja s tvojim profilom obnašanja.
Dokler se giblješ v okviru svojega biometričnega oz. 'behavioral' profila, ti kaj dosti ne težijo. Čim pa se pojavi odstopanje, pa se prične z dodatnimi preverjanji identitete oz. se te vrže ven iz accounta.

No, vse lepo in prav - a kot kompromitirani uporabnik spet ne veš, da se je to zgodilo, če ti je npr. hotel mulc izvesti plačilo za nov e-skiro na Aliexpress (user&pin pa je posnel z GoPro-jem, ko si ga vnašal).

Meni npr. povsem ustreza, da mi vleti SMS, kadarkoli se prijavim v Klik (z certifikatom). Če bi se kdorkoli dokopal do gesla in ključka z certifikatom, imam še vedno neko opozorilo, da se nekaj dogaja.
Nimaš pa več nobenega nadzora nad tem KAJ se je zgodilo, če ti je bil ključek ukraden.

Podobno je pri plačilih z kreditno kartico. Saj je lepo, da te obvestijo z SMS, da se je zgodila transakcija - a je takrat že prepozno, saj nimaš možnosti, da bi na telefonu kliknil "NE DOVOLIM!".
Obratno pa bi dejansko lahko poslal mulca s svojo kartico v trgovino in lepo na daljavo 'blagoslovil' plačilo.

Skratka ni vse SAMO v zanesljivi potrditvi identitete. Stvari so lahko bistveno bolj fleksibilne in bistveno dvignejo nivo varnosti bančnega poslovanja, če so pravilno implementirane, istočasno pa uporabniku dajo boljši občutek varnosti in nadzora nad svojim računom.

Torej talanje Ubikey-ev (zakaj vraga ravno Ubikey? saj so še drugi Fido certificirani ponudniki ključev!) za mene ni rešitev, saj pokriva samo en segment v celi zgodbi - katerega pa lahko potencialno celo poslabša, namesto da bi ga izboljšal (če ga uporabiš na način na katerega ga promovirajo).
Ker pa banke zagotovo nebi ničesar kar tako 'talale', temveč bi to pridno zaračunale komitentom, je zelo vprašljivo, če je še dopustno, da komitentu nabiješ 50€ stroška za tisti ključek, ki na koncu vsega tudi ni neuničljiv.

Kakorkoli obrneš, tisto z točno 8-mestnim številom, pa je resnično bad joke....
Ampak ok...če so zadaj obesili analitiko obnašanja uporabnika... potem pa morda niti ni tako slab ta joke... (samo kaj, ko ne verjamem, da so investirali v kaj takega, saj bi se drugče že hvalili po vseh medijih).

techfreak :) je 3. sep 2020 ob 21:21 izjavil:

YubiKey podpira x.509 certifikate, podobno kot Gemalto in podobni USB kljuci. Mogoce se tudi to spreminja, ampak poslovni uporabniki so vcasih dobivali pametno kartico in bralnik, oz. USB kljucek s certifikatom.

Ne govorim o tem. Ampak o tem, da Francelj dobi YubiKey od NLB. Potem dobi YubiKey od FURS. Potem odpre še en bančni račun na NKBM in ima zdaj 3 YubiKey-e (in poln kufr...).

Razen, če je prenos ključev med YubiKey-i preprost, da bi potem imel vse v enem. Kar pa dvomim.

Veliko telefonov ima NFC. Vse naše kartice imajo NFC. Zakaj hudiča se ne da porabit bančne kartice za en faktor avtentikacije? (+ seveda še nekaj)

SeMiNeSanja je 3. sep 2020 ob 21:52 izjavil:

Mathai predlaga Ubikey. Meni ta metoda ni všeč, ker bi se jo z 99,9% verjetnostjo uporabilo kot enofaktorsko avtentikacijo - ukradeš ključ in lahko neovirano dostopaš do accounta, ne rabiš več ne userja, niti geslo, saj imaš ključek.

Če želiš dostopat do certifikata na Yubikey, ga moraš odklenit s PIN-om (geslo, sestavljeno iz poljubnih znakov, ki si si ga nastavil na začetku). Če se nekajkrat zmotiš, moraš vnesti PUK, ki si si ga nastavil na začetku. Če se še tu nekajkrat zmotiš, se vsebina ključa uniči.

jlpktnst je 4. sep 2020 ob 07:45 izjavil:

Veliko telefonov ima NFC. Vse naše kartice imajo NFC. Zakaj hudiča se ne da porabit bančne kartice za en faktor avtentikacije? (+ seveda še nekaj)

Tudi Yubikey ima NFC. Ga še nisem uporabljal, ampak precej uporabna zadeva, če želiš s telefonom kaj plačati in imaš certifikat na Yubikeyju. To bo seveda enkrat uporabno, ko bodo bankirji prerasli 4-mestni PIN iz številk za dostop do mobilne bančne aplikacije.

borko je 4. sep 2020 ob 11:44 izjavil:

MrStein je 4. sep 2020 ob 00:08 izjavil:

Ne govorim o tem. Ampak o tem, da Francelj dobi YubiKey od NLB. Potem dobi YubiKey od FURS. Potem odpre še en bančni račun na NKBM in ima zdaj 3 YubiKey-e (in poln kufr...).

Ne, katerikoli Yubikey lahko registriraš kot 2FA. Podobno, kot se je dalo v preteklosti "registrirati" sigenca cert.

Saj to pravim, v teoriji mogoče gre, v praksi pa SIGEN-CA nisi mogel "registrirati" za Klik.NLB. (in niti danes ne moreš)

Enako se lahko odločijo, da podprejo samo "svoj" YubiKey in nič drugega.

SKB ima RSA "kalkulatorček"... pa uporabnikom kar funkcionira.

Če je pa tak problem naj se pa ukine vsa gesla... jih uporabniki vsaj pozabiti ne bodo mogli... pa ne bo treba nobenega oddelka.

Najbolj pa sem sovražil pretipkavanje tistih challenge&response kod.

Alternativa je aplikacija, kjer dobis potisno sporocilo s podatki o placilu, ob kliku na gumb pa potrdis transakcijo (v ozadju pa se seveda naredi challenge & response glede na zasebni kljuc shranjen v telefonu.) Podobno kot imajo "mobilne" banke urejeno za 3D Secure.

MrStein je 4. sep 2020 ob 15:25 izjavil:

Saj to pravim, v teoriji mogoče gre, v praksi pa SIGEN-CA nisi mogel "registrirati" za Klik.NLB. (in niti danes ne moreš)

Aha, NLB ima kot kaže drugačna pravila. Pri Abanki se je dalo "registrirati" sigenca cert.

OMG, v tem sporočilu je narobe tako veliko stvari, da bi skoraj mislil, da je tole fejk Oh, ja...

Qushaak je 10. sep 2020 ob 06:31 izjavil:

Jaz bi takoj dal, da gredo banke na Web Authn standard pa da lahko svoj ključek prijaviš. Pa recimo kot majo "veliki", da maš nek self-service portal da registriraš nov (backup) ključ oz več njih pa stare skenslaš.

YubiKey pa bo kmalu očitno dal ven zanimiv ključ: https://www.yubico.com/blog/yubico-reve...

Še vedno pa jasno (vsaj zame) passwordless ni dovolj dober da bi se odreklo MFA. Sam se najbolj nagibam k mobile app + ključ.

Glavni problem je podpora na strani banke. Kot prvo, ni tam zunaj le yubico, ampak imaš še kopico drugih ponudnikov ključkov. Večinoma so se naše banke nekako 'priučile' na uporabo in podporo Gemalto ključkov. Vsak dodatni proizvajalec pa s seboj prinaša svoje muhe, finte in fore. Potem pa imaš še uporabnike, s katerimi do včeraj nisi imel težav, ker je SMS 'deloval', zdaj pa nenadoma ne vedo kam vtakniti ključek, ki so ga dobili ne vem kje...

Nekako je to tako, kot če odpreš pandorino skrinjico...

Že res, da naj bi bile stvari načeloma kompatibilne.
Problem je vedno v drobnem tisku...

Nikakor pa si ne želi lock-in na Yubico. Potem raje vidim, da se nobene ključke ne podpira.

> Poanta je tem, da bi morali izbrati neko standardizirano rešitev

Kdo, banke?

Od milijonov mailov, ki jih dobivam, so podpisani tam trije (mislim na pošiljatelja, taki vsak mail podpišejo). Ponavadi S/MIME.
Na mail listah pa se včasih kot oaza v puščavi najde kaki PGP podpis.

Tako da ja, podpisani emaili se niso prijeli. Niti za uradna sporočila, kaj šele druga. (v bistvu so bolj pogosto podpisana neuradna)

Web Authn pa ni "standard", ki bi rešil večino teh problemov?
WebAuthn @ Wikipedia

BlaY0 je 15. sep 2020 ob 13:33 izjavil:

Bolj malo bi vse skupaj pomagalo. Nič ne pomaga podpis pošiljatelja, če ga prejemnik ne zna preverit. Problem pri 99% prejemnikih je že, da jim ni jasno kaj je e-naslov in kaj display-name od tega e-naslova. Za 99% ljudi je podpisan mail......

Kar si napisal že drži....

A ravno to je čar podpisa z certifikatom - Outlook te že ob odpiranju maila opozori, da je nekaj narobe z certifikatom!

Ravno tako nisem prepričan, če mi Outlook dovoljuje podpisovanje maila z drugim display name-om, kot je tisti mail naslov, ki je 'zapečen' v certifikatu (bi moral preizkusiti).

Ne morem pa zdaj reči, kako 'reagirajo' drugi mail programi. Lahko da so bolj 'popustljivi' in samodejno ne preverjajo certifikatov že ob samem odpiranju sporočila. Vsekakor pa ti bolj ali manj vsi mail programi ponujajo neko možnost klika za preverbo pristnosti certifikata.

@SeMiNeSanja

Saj sem ti dal konkreten primer... mail bo podpisan s certifikatom od ef13a4bb@nospam.com in bo vsaj kar se samega certifikata tiče čisto legit. Prejemnik bo videl v From: polju joze.podbevsek@gov.si (v display name-u) in nobenega opozorila. Takšnih bo 99% prejemnikov. Od preostalega procenta jih bo pa polovica pogledalo certifikat in se jim bo še vedno vse zdelo OK (predpostavljajo, če tam piše nospam.com potem je sigurno varno), polovici pa recimo da ne bo všeč.

Kar se tiče subjectAltName pa je mail definiran kot rfc822Name ki pa je v bistvu mailbox name po rfc2821 in ne predvideva, da pred njim stoji še kaj, recimo CN.

Teh primerov bo čedalje več... vse kar rabiš je nek kompromitiran intermediate CA, ki je še valid, da si naštancaš certifikate in piči miško.

MrStein je 15. sep 2020 ob 15:06 izjavil:

Account email address in e-naslov v certifikatu se morata ujemati, vsaj v Outlook 2019.

V tem primeru se vse ujema. Display name pa ni del certifikata.

Da. Za 99% ljudi. Bistvo je zmesti ljudi, ki ne vedo za kaj gre. Kaj pa Average Joe ve kaj je recimo ef13a4bb@nospam.com. On samo vidi zeleno kljukico.

Ker ni nihče od šefov udaril po mizi in rekel, da je to pa treba implementirati.

Mail serverje imajo kar dobro poštimane, manjka pa pika na i: DMARC policy: https://telefoncek.si/2020/08/28/varnos...

...ker noben šef ni zatežil, da je to pa treba urediti do konca.

BlaY0 je 16. sep 2020 ob 13:44 izjavil:

SeMiNeSanja je 15. sep 2020 ob 23:22 izjavil:

Zakaj ne!?!

Ker ne prispeva k večji varnosti, takoj ko eden od vpletenih nima pojma (zgornji primer to potrjuje). Ponavadi v uradnem odgovoru itak dobiš PDF, ki pa je podpisan, tvoj Acrobat (Reader) pa podpise preverja po EUTL, česar za enkrat ne počne noben mail klient (vsaj kolikor jih jaz poznam).

To, da je dokument podpisan, je druga zgodba. Tak podpis ti prav nič ne pomaga pri odločitvi, ali je varno ta dokument odpirati ali ne. Zato potrebuješ podpis (tudi) na mailu, da se tisti, ki mu je do tega, lahko prepriča, ali je vir sporočila pristen ali fake in se potem na osnovi tega odloči tvegati z klikom na priponko.

Seveda tudi to ni 100% zanesljiva zaščita. Teoretično bi lahko kakšen barabin okužil Outlook, ki bi pridno čakal, da podpišeš prvi mail. Takrat namreč vpišeš pin za podpis, pri naslednjih pa ne sprašuje več (pa še to samo, če imaš cert na ključku?).
Ko okužbi na tak način 'odpreš vrata', pa bi ta lahko pričela razpošiljati malware v mailih s popolnoma pristnim digitalnim podpisom.

A hudirja, ko je tako zoprno za vsak mail posebej klofat pin, pa je treba stvari čim bolj poenostaviti...

BlaY0 je 16. sep 2020 ob 14:54 izjavil:

Zakaj ti ne pomaga? Za varno odpiranje dokumenta ti služi virus skener, ne pa podpis na mailu.

Ti dam primer... v kaslc dobiš listek, da te na pošti čaka priporočeno pismo. Prideš tja, podpišeš in v roke dobiš kuverto z glavo Bele Hiše. Najprej si rečeš hmm, kaj pa če je bomba notri. Verjetno ni, ker je priporočeno pa še od Bele Hiše, to vsi poznajo pa nekdo je moral podpisat da je kuverto oddal. Prideš domov, odpreš in te raznese. Kaj je šlo narobe? Ajd, pa recimo da ni bilo notri bombe... odpreš in notri je pismo z glavo ter žigom Bele Hiše in podpisom Donalda Trumpa. Zgleda pristno. Kako boš zdaj preveril, ali je pismo zares prišlo od Donnyja?

Tehnično gledano koncept podpisovanja je OK. Problem tiči točno v tem kar si v zadnjem stavku omenil, da se je z raznimi kvazi user-friendly rešitvami in poenostavitvami na strani končnih uporabnikov, varnost bistveno poslabšala, saj je korakov v procesu vedno več in vsak od njih je lahko kompromitiran. Zadeva zgleda nekako tako, banaliziram... v bajti brez alarmne naprave v sefu naprintanim z domačim 3D printerjem hraniš ful hude ključe ki odpirajo JP Morganov trezor. Poleg tega ti na predpražniku pred bajto piše kje se nahaja ta sef, ključ od bajte je pa verjetno pod tem istim predpražnikom.

Na, zdaj si pa v celoti izničil vrednost digitalnega podpisa.
Isto, kar trdiš za ovitek (mail) namreč lahko trdiš za podpisan dokument.

Bistveno pa je, da pozabljaš, da digitalno podpisovanje že v sami osnovi temelji na zaupanju. Torej posledično tudi podpis ni nič drugega, kot sredstvo, s katerim ustvariš višji nivo zaupanja v izvor neke vsebine. Na koncu ti še tako tehnično dovršene rešitve ne morejo pomagati, če npr. ne moreš zaupati izdajatelju certifikata.

Kljub temu, pa je razlika nekako taka, kot če imaš ovojnico, ki ima v tiskarni natisnjen naslov pošiljatelja in na roke napisanega. Kateremu lahko BOLJ ZAUPAŠ, da je pristen? Lahko sta oba, lahko ni nobeden, a nekako ti vendarle logika pravi, da je originalno natisnjeni nekako bolj verodostojen.

Kot že rečeno, pa ovojnica ne more pričati o vsebini. O tem sploh nismo razglabljali. Šlo se je zgolj za to, ali mi bo digitalni podpis dal toliko gotovosti, da mi je mail dejansko poslala oseba, katera je navedena kot pošiljatelj. Da ne rabim dvigniti telefonske slušalke za vsak mail s priponko in pred odpiranjem te vprašati pošiljatelja "ali si mi res ti poslal sporočilo z priponko?"

Drugače povedano: Vsak avto ima zavore - čeprav vsi vemo, da zavore ne morejo preprečiti vseh nesreč. Kljub temu, pa nihče noče avtomobila brez zavor. Pardon - niti NE SME voziti avta, na katerem zavore nebi delovale!

Digitalni podpis na elektronskem sporočilu tudi ne more preprečiti vseh zlorab - pa je to potem že dovoljšni razlog, da se ne teži k splošnemu podpisovanju elektronski sporočil (vsaj ko se gre za državno upravo in podobne ustanove/organizacije) ?

BlaY0 je 16. sep 2020 ob 16:57 izjavil:

Ja, noben noče avta brez zavor, čeprav ni nujno da sploh ve kje je zavorno pedalo oziroma kako se uporablja. Ampak tu obstaja varovalka, izpit je obvezen.

Skratka "rabimo" nekaj, česar sploh ne znamo uporabljati. 99% ljudi, ki uporablja mail ne ve kaj je to digitalni podpis oziroma kako se ga uporablja. Mogoče bi bilo pa treba uvesti obvezen izpit ;)

No, ne samo to - tudi izdajatelji digitalnih certifikatov bi se lahko potrudili in preverili, da njihovi certifikati dejansko delujejo v najbolj uporabljenih mail programih.

Sem že enkrat opisoval primer, ko sem hotel naučiti mojo računovodkinjo, da mi dokumente pošlje kriptirane z certifikatom - pa ji zadeva nikakor ni delovala. Sprva sem mislil, da sem kaj narobe narekoval po telefonu, na koncu pa se je izkazalo, da Halcom-ov certifikat nekako ni bil 'dovolj kompatibilen' z Outlook-om. to je bilo kakšne dve - tri leta nazaj in ne vem, če je stvar danes kaj bolj 'kompatibilna'.

Skratka ne moreš verjet, da izdajatelju ne pride na misel, da bi preveril, če mu certifikat deluje kot bi pričakoval.... (še vedno mi sicer ni jasno, kako nek cert 'ni kompatibilen', a dejstvo je, da ji šlo...kvazi nek bug...)

.. Če ima kdo Halcom-ov cert in Outlook, bi bilo zanimivo slišati, če mu stvar danes deluje.