» »

Analiza slovenskih gesel

Infosec.si - Gorazd Žagar je na svojem blogu Infosec.si tokrat objavil zanimiv prispevek o geslih, ki jih za različne internetne storitve izbiramo uporabniki.

Na spletu najdemo kar nekaj analiz gesel, vendar gre večinoma zgolj za gesla iz angleškega govornega področja. Gorazd Žagar pa je tokrat pripravil analizo gesel slovenskih uporabnikov. Seznam zajema skupno 55.096 gesel, pridobljenih v letih od 2001 do 2006 iz različnih virov.

Najpogostejše slovensko geslo je 123456, precej pa jih vsebuje tudi lastna imena. Vsekakor gre za zanimivo analizo, ki kaže na pogoste napake uporabnikov pri izbiri gesel, zato si jo vsekakor velja ogledati.

39 komentarjev

Bistri007 ::

Seznam zajema skupno 55.096 gesel, pridobljenih v letih od 2001 do 2006 iz različnih virov.

ROFL

To pa je varno, da so shranjena brez hash+salt? Sicer pa so se mogoče od 2001-06 navade že spremenile?
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

Zgodovina sprememb…

  • spremenilo: Bistri007 ()

Damiani ::

in pridobilo novo vrsto uporabnikov

RejZoR ::

Ti novi uporabniki so bolj zviti in ne uporabljajo 123456. Sedaj uporabljajo 654321.
RejZoR's Flock of Sheep @ rejzor.wordpress.com

Izi ::

Krivda je tudi na strani programerjev. Zadnje čase opažam, da bodo gesla 123456 ali lastna imena kmalu postala neuporabna, ker večina programov poleg najmanjše dolžine gesla 6 znakov zahteva vsaj eno črko in vsaj eno številko.

kriko1 ::

Bo pa 123456a :D

ThinMan ::

Motiš se. Bo kar 123456z ali 123456t :)

Predlog za wifi pass 'daj mi internet' :)
----
It is impossible to make anything foolproof because fools are so ingenious.

Zgodovina sprememb…

  • spremenil: ThinMan ()

vorantz ::

Ena2Tri4Pet6
to bi mal bolš zdržalo :P

Jst ::

>Zadnje čase opažam, da bodo gesla 123456 ali lastna imena kmalu postala
>neuporabna, ker večina programov poleg najmanjše dolžine gesla 6 znakov zahteva
>vsaj eno črko in vsaj eno številko.

Jaz sem pa opazil, da nekateri programi dovolijo samo črke in številke, ter da mora biti prvi znak črka. Pa da je recimo omejeno na samo določeno število znakov 6-10, ali kaj podobnega.

Recimo ! odpade. In pri takem butastem sistemu odpade moj algoritem za gesla. CRAP!
Proton decay is a tax on existence.

techfreak :) ::

Gesla so bila brute forceana ali so dobili v plain textu? Ker 55k ni malo število.

-Nevsky- ::

Jaz sem pa opazil, da nekateri programi dovolijo samo črke in številke, ter da mora biti prvi znak črka. Pa da je recimo omejeno na samo določeno število znakov 6-10, ali kaj podobnega.


Podobno neumen sistem gesel ima nlb klik. Dovoljene so samo črke in številke, pa še dolžina gesla je omejena.

Matthai ::

Kolikor jaz vem, so bila pridobljena v plaintextu.
Zloraba oblasti, avtokracija in tema nikoli ne pridejo hipoma, vedno je vmesno
obdobje mračenja, ko se dan preveša v noč; biti moramo pozorni opazovalci
okolja in varuhi luči, da ne postanemo nemočni ujetniki teme. --W. Douglas

techfreak :) ::

Mene najbolj moti to, da sem omejen na največjo dolžino ter na A-z in 0-9.

Recimo tudi na malo bolj resni strani RackSpace Cloud imajo omejitev A-z0-9, poleg tega pa bi naj imeli shranjeno v plain text. Administracija kjer urejaš vse podatke o oblačnih strežnikih bi morala biti malo bolj zavarovana.

fosil ::

Krivda je tudi na strani programerjev. Zadnje čase opažam, da bodo gesla 123456 ali lastna imena kmalu postala neuporabna, ker večina programov poleg najmanjše dolžine gesla 6 znakov zahteva vsaj eno črko in vsaj eno številko.

Že tretje geslo na seznamu najbolj popularnih abc123 izpolni vse pogoje za "dobro" geslo.
Pač v skladu z izrekom: It's impossible to make things fool proof, because fools are so ingenious.
Tako je!

Relanium ::

In kak si kaj vi zapomnite 20 različnih gesel ?
Js si jih vrjetno nebi, zato mam 2-3 različne za vse drek kar ga rabim.

Kami ::

Jst je izjavil:

>Zadnje čase opažam, da bodo gesla 123456 ali lastna imena kmalu postala
>neuporabna, ker večina programov poleg najmanjše dolžine gesla 6 znakov zahteva
>vsaj eno črko in vsaj eno številko.

Jaz sem pa opazil, da nekateri programi dovolijo samo črke in številke, ter da mora biti prvi znak črka. Pa da je recimo omejeno na samo določeno število znakov 6-10, ali kaj podobnega.

Recimo ! odpade. In pri takem butastem sistemu odpade moj algoritem za gesla. CRAP!


Se strinjam, to je grozno.

Žalostno pa je, da je v zadnjem času takšnih spletnih strani in aplikacij vedno več.

Namesto, da bi podpirali "varna" gesla te dejansko prisilijo, da uporabiš krajšega in manj varnega.
http://www.ubuntu.si || http://www.freebsd.si

BlueRunner ::

Bistri007 je izjavil:

Seznam zajema skupno 55.096 gesel, pridobljenih v letih od 2001 do 2006 iz različnih virov.

ROFL

To pa je varno, da so shranjena brez hash+salt? Sicer pa so se mogoče od 2001-06 navade že spremenile?


Kar se tiče hash + salt oziroma shranjevanja izvlečka (digest) namesto samega gesla je to vezana trgovina. Če shraniš izvleček, potem se lahko uporabik izkaže samo s posredovanjem dejanskega gesla. Če shraniš plain-text oziroma njegov ekvivalent, pa lahko uporabnik pri avtentikaciji uporabi varnejše protokole, ki gesla ne izpostavijo preko povezave (SSL gor ali pa dol, MITM-i so v podjetjih hvala dobro in še kako živi).

Rešitev pa je itak v upoarbi drugih mehanizmov, ki pa še niso čisto do konca dozoreli... so pa tam, tam.

Mavrik ::

Kaj ma način transporta gesla veze z načinom shranjevanja le-tega?
Krivda je tudi na strani programerjev. Zadnje čase opažam, da bodo gesla 123456 ali lastna imena kmalu postala neuporabna, ker večina programov poleg najmanjše dolžine gesla 6 znakov zahteva vsaj eno črko in vsaj eno številko.


Neumnosti uporabnikov se ne rešuje s tehnologijo. Vsa ta pravila so se na koncu izkazala vedno kot samo še manj varna, saj začnejo uporabniki svoja gesla pisati na listke in jih lepiti okoli po monitorjih, ker admini od njih zahtevajo večjo kompleksnost, kot si jo lahko zapomnijo na pamet.
The truth is rarely pure and never simple.

Zgodovina sprememb…

  • spremenil: Mavrik ()

Looooooka ::

Neumnost se resujes kaznovanjem.Takoj ko mu bodo pobrali kaj z racuna...bo problem resen.
Zakaj bi pa mogl obremenjevat sisteme z 20imi poskusi registracije ce pac bebec ne razume, da njegovo ime pac ni dobro geslo.
Naj fase na lastnem wallu na fb-ju oz twitterju msg "I AM GAY" pa bo.
Pa upam, da ti ljudje na ebayu hranijo vse podatke svoje kreditne kartice.Da bo se bl smesno...

.:joco:. ::

Pomojem bi moglo bit shranjevanje gesel brez hash-a na javnih page-ih kaznivo.
"Is science true?"
You don't get it.
Science is the process of trying to find out what's true.

Ziga Dolhar ::

Še en "rant" - prejšnji eŠtudent (ki ga je sproduciral odlični Gambit), je geslo (privzeto geslo VSEH študentov je bil rojstni datum ... že zaradi tega si zaslužijo izumrtje) omejil na 6 poljubnih znakov, as long as they were numbers.
Legal systems are not supposed to be efficient. They are
designed to ensure that innocent people are not found guilty.
If that requires inefficiencies, so be it.

Mavrik ::

Kateri točno je tale "prejšnji"? Namreč eŠtudentov je kar nekaj :)
The truth is rarely pure and never simple.

BlueRunner ::

.:joco:. je izjavil:

Pomojem bi moglo bit shranjevanje gesel brez hash-a na javnih page-ih kaznivo.

Niti pod razno ne moreš tega razglasiti za slabo prakso. Včasih preprosto ne gre drugače in se moraš poslužiti drugih metod varovanja.

Marsikje SSL preprosto ni v uporabi ali pa zaradi objektivnih okoliščin ni uporaben. Varna uporaba skupne skrivnosti (gesla) pa v teh primerih nujno pomeni, da je shranjeno izvorno geslo ali pa njegov ekvivalent.

Zgodovina sprememb…

Ziga Dolhar ::

Mavrik: "tisti" eŠtudent od Gambita, ane :). K je imel še linke do enaa štacune. PF ga je uporabljala od nekje septembra 2003 do jeseni 2008, se mi zdi.
Legal systems are not supposed to be efficient. They are
designed to ensure that innocent people are not found guilty.
If that requires inefficiencies, so be it.

.:joco:. ::

@BlueRunner, no.. Tako narejen app, da server admin ali webdeveloper lahko vidi gesla, bi moglo bit kaznovano.
"Is science true?"
You don't get it.
Science is the process of trying to find out what's true.

Bistri007 ::

.:joco:. je izjavil:

@BlueRunner, no.. Tako narejen app, da server admin ali webdeveloper lahko vidi gesla, bi moglo bit kaznovano.

To moraš predpostavljati, da je.

Zato imaš, po prioriteti:
1. posebno geslo za finančne strani - Klik, PayPal...
2. email geslo
3. spletne trgovine
----------
4. forumi ipd.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

.:joco:. ::

ja
Samo škoda ker ni kaznovano.
"Is science true?"
You don't get it.
Science is the process of trying to find out what's true.

BlueRunner ::

.:joco:. je izjavil:

@BlueRunner, no.. Tako narejen app, da server admin ali webdeveloper lahko vidi gesla, bi moglo bit kaznovano.

Eh. Saj vem kaj te žuli in tudi sam sem včasih podobno razmišljal.

Potem pa butneš na težave. Tipičen primer:
- SIP signalizacija deluje preko UDP
- realizacija šifriranja ni trivialna
- pri prenosu avtentikacije se tako uporabi metoda izvlečka (digest authentication)
- s tem se prepreči napade s ponovnim predvajanjem in prestrezanje gesel
- hkrati pa so zaradi tega na SIP strežniku shranjena plain-text gesla uporabnikov

Skrbnik sistema ima tako vpogled v vsa ta gesla, saj ima enake pravice kot jih ima aplikacija, ki vrši avtentikacijo. Čisto realna situacija, čisto vsakdanja rešitev in čisto nerealna zahteva, da bi "kaznovali" skrbnike takšnih sistemov.

Potem pa se naučiš, da se varnost ne zagotavlja samo s tehničnimi ukrepi ampak tudi z organizacijskimi. Ena izmed možnih rešitev za tvojo dilemo je tako:
- skrbnik aplikacije sicer lahko vidi gesla, vendar pa se ta dogodek zabeleži - pusti sled
- dogodek se zabeleži tako, da ga skrbnik aplikacije več ne more spremeniti ali izbrisati
- skrbnik strežnika lahko prepreči zapis sledi o vpogledu, vendar pa to povzroči novo sled, katere zapis skrbnik ne more preprečiti.

Temu se sicer reče obvladovanje tveganja z uvedbo revizijske sledi (audit trail) in delitvijo odgovornosti (separation of duties). Pravilna organizacija tako zagotovi, da skrbnik sicer lahko vidi gesla, vendar pa tega vpogleda ne bo mogel zanikati, oziroma ga bo moral utemeljiti. Sicer sledi odpoved ali še kaj bolj radikalnega. V splošnem pa je zaradi nadzora, če se ga res izvaja, tudi motivacija privilegirane osebe za odgovorno delo mnogo večja, kot pa brez nadzora.

Roadkill ::

55k je ravno kak seštevek vseh slovenskih članov PHPbb forumov, ki so bili v začetku 21. stoletja zelo ranljivi.
Vseeno impresivna količina gesel in precej zanimivo, da se je šel avtor (odličnega) bloga tako izpostavit.

Bi bil zelo vesel, če bi razkril naslove strani, ki so prispevale največ gesel.
Ü

krho ::

Še en primer, ko rabiš na strežniku plaintekst gesla. Avtetikacija za pop3,imap,smtp. Tu imaš pač 2 možnosti. shraniš gesla v plaintext in dovoliš vse tipe avtetikacije. Zakriptiraš gesla v določen hash, ter focaš, samo plain tekst avtetikacijo.
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net

BlueRunner ::

Res je. Kjerkoli vidiš avtentikacijo z geslom, kjer se geslo ne prenaša v plain-text, je na strežniku vedno shranjena plain-text verzija ali njen ekvivalent.

Rešitev je bodisi odmik od gesel, kar je že tako ali tako dobra smer, ali pa uvedba ustreznih tehničnih in organizacijskih postopkov, ki ta gesla varujejo pred nenamernim razkritjem.

Bistri007 ::

Jaz ne vidim razloga, zakaj bi moral imeti plain text gesla shranjena na strežniku. Kar lahko počneš s plain text, lahko počneš tudi s hashem.

Npr. Javascript v brskalniku lahko spremeni geslo v md5 in ga pošlje naprej kot geslo. Isto seveda z dodatnimi nivoji enkripcije.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

Zgodovina sprememb…

  • spremenilo: Bistri007 ()

BlueRunner ::

Npr. Javascript v brskalniku lahko spremeni geslo v md5 in ga pošlje naprej kot geslo.

Jaz pa iz baze preberem te MD5 hashe in jih preko svoje JS funkcije posredujem naprej kot geslo. Vse kar sem s tem storil je to, da sem namesto gesla samega shranil ekvivalent gesla. Nisem pa s tem rešil kaj veliko, saj lahko že samo z ukradenim MD5 hashom izvedem uspešno avtentikacijo. Edino kar sem dosegel je to, da ne more skrbnik sistema A uporabiti istega gesla na sistemu B, ki ne uporablja istega pristopa. Nekaj je, ni pa to veliko... torej več ni cross-polination ranljivosti, ni pa sistem A zaradi tega čisto nič bolj varen ali pa zavarovan.

Isto seveda z dodatnimi nivoji enkripcije.

Enkripcija ponekod ni praktično izvedljiva. Bilo bi lepo, če bi bila, na žalost pa ni ali pa je (tipično) implementirana na način, ki ne preprečuje MITM napadov in s tem v celoti negira ugodnosti šifriranja.

Zgodovina sprememb…

Bistri007 ::

BlueRunner je izjavil:

Vse kar sem s tem storil je to, da sem namesto gesla samega shranil ekvivalent gesla. ... Nekaj je, ni pa to veliko... torej več ni cross-polination ranljivosti, ni pa sistem A zaradi tega čisto nič bolj varen ali pa zavarovan.

Vsak dodaten element, ki nekaj prispeva k varnosti, je dobrodošel. Če veš, kakšno geslo nekdo uporablja, se lahko prijaviš tudi v druge sisteme. Saj ravno to je poanta ranljivosti shranjevanja v plain text.

Dodatne rešitve so, če poleg gesla uporabljaš še:
1. SMS,
2. certifikate,
3. generatorje števil.

Če gre za denar, se to že danes uporablja. Če gre za neke klepetalnice, pa to ni tako pomembno.

Je pa danes najšibkejša točka email, z dostopom do katerega lahko narediš veliko škode uporabniku. Email še zdaleč ni tako zaščiten kot ebančništvo, čeprav lahko s krajo identitete povzročiš finančno škodo človeku. Poleg tega da zveš še veliko nejavnih osebnih in poslovnih infomacij.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

BlueRunner ::

Vsak dodaten element, ki nekaj prispeva k varnosti, je dobrodošel. Če veš, kakšno geslo nekdo uporablja, se lahko prijaviš tudi v druge sisteme. Saj ravno to je poanta ranljivosti shranjevanja v plain text.

Hm. Načeloma res. Samo je pa potrebno biti previden z oceno koliko več varnosti se je doseglo in v katerih primerih. Marsikdaj pa takšnega pristopa ni možno uporabiti.

Dodatne rešitve so, če poleg gesla uporabljaš še:

Moje (spregledano) mnenje je tukaj.

Je pa danes najšibkejša točka email, z dostopom do katerega lahko narediš veliko škode uporabniku.

Da in ne. Kdor misli, da je e-mail verodostojna oblika komunikacije, je v zmoti (laično ali strokovne ju druga težava). Lahko pa se uporabi S/MIME ali podobne mehanizme za zagotavljanje avtentičnosti, integritete in/ali zaupnosti, vendar pa so ti bodisi a) polomljeni, b) premalo razširjeni, da bi bili uporabni. Torej to je šibka točka, vendar pa to ni nujno, če je človek strokovnjak, po drugi strani pa ne vem za e-poštnega odjemalca, ki bi digitalna potrdila uporabljal na pravilen način (hud lapsus prvotnih načrtovalcev S/MIME protokola).

Če pa se vrnemo nazaj k geslom in z njimi povezanimi krajami identitete, pa je moja osebna ocena nevarnosti od največje do najmanjše sledeča:
A) Odtujitev gesla preko phishing in njim sorodnih napadov (npr. password harvesting boti)
B) Preveč enostavno geslo
C) Geslo, ki se ga da uganiti iz javno objavljenih uporabnikovih podatkov
D) Večkratna uporaba istega gesla - največja nevarnost je uporaba istega gesla za e-poštni račun IN spletno storitev kjer se s tem registriraš
E) Zloraba znotraj kroga prijateljev/znancev/sodelavcev preko kršitve splošnega načela "ne prilepi gesla na monitor" (nič pa ni narobe, če je geslo napisano na listek, listek pa je v denarnici).
F) Prestrezanje gesel s strani upravitelja omrežja v podjetju

Izrecno pa sem iz seznama izpustil možnost prestrezanja gesla v okoljih cybercafee/hotelov/WiFi/... Tam je privzeto, da se promet najverjetneje spremlja in je kakršna koli uporaba nezaščitenih povezav naravnost iskanje težav (mimo gesel je tukaj še problem t.i. session hijackinga s pomočjo kraje piškotkov).

Ravno tako sem izpustil krajo gesla s strani skrbnika sistema. Ta lahko sicer ukrade celotno zbirko gesel in z njo počne kaj tretjega, za lokalno zlorabo pa gesel tako ali tako ne potrebuje. Če se uporabnik drži tega, da pazi pri večkratni uporabi gesla, potem je kraja gesel nenevarnost. Če se tega ne drži, je pogosto žrtev točke C).

MrStein ::

1.) Od kod taka gesla: http://www.jboss.org/dms/announcements/...
(plain text passwords)

2.) Argument, da md5 has nič ne pripomore je ubogi. Na istem sistemu namreč admin ima dostop ne glede na vse (razen če je izjemen dizajn, samo v 99% ni). Z omenjenim postopkom (Bistri007) dobimo ravno kar hočemo: ownan site A ne ogrozi accounta na site B. Da ima admin site A dostop do accountov na site A pa velja v vsakem primeru. Torej je to definitivno korak naprej.

PS: Imenovanje folka neumni še nikoli ni rešilo problem. Kdo je neumen? Ovca ki pade v prepad ali nesposoben pastir, ki svoje ovce izgublja? Če je pastir zaposlen v JU mogoče ovce, v sistemu, kjer ima vsak svojo odgovornost, pa sledi "Adijo pastir, izgovore pričaj drugim na zavodu". ;)
Teštiram če delaž - umlaut dela: ä ?

Zgodovina sprememb…

  • spremenil: MrStein ()

BlueRunner ::

Z omenjenim postopkom (Bistri007) dobimo ravno kar hočemo

To je samo ena izmed stvari, ki "jih hočemo". Sem rekel, da je ni kar tako odpisati, ampak ni pa to edina in IMHO tudi ne najbolj pomembna stvar.

Bistri007 ::

Za vsak varnostni ukrep lahko narediš cost-benefit analizo. Če več prispeva k varnosti kot je nadležna njegova implementacija, potem ga sprejmeš. Če ne pa pač ne.

Geslo na strežniku je shranjeno v md5(pw+salt). Prijava preko brskalnika poteka pa z md5([pw+salt]+oneTimeSalt), ki ga izračuna JavaScript.

oneTimeSalt določi spletni strežnik, veljaven je 15 sekund (dobiš ga z AJAX ko stisneš gumb za prijavo oz. že ko tipkaš geslo), cookie pa je vezan na tvoj prvotni IP, in se pobriše, če AJAX v brskalniku ne odgovori pravilno na tri zaporedne uganke. Te uganke lahko pravilno rešiš samo če poznaš zadnje tri uganke oz. njihove odgovore.

Vse to poteka preko https, kompatibilno pa z vsakim (tudi mobilnim) brskalnikom z JS.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...

JohanP ::

zjutraj mi je tole priletelo na mail.
hec on

During a recent password audit in a company, it was found that one blondie
was using the following password:

MickieMinniePlutoHueyLouieDeweyDonaldGoofySacramento

When asked why such a long password, she said she was told it had to be 8
characters and include at least one capital.

hec off

BlueRunner ::

Bistri007 je izjavil:

Za vsak varnostni ukrep lahko narediš cost-benefit analizo. Če več prispeva k varnosti kot je nadležna njegova implementacija, potem ga sprejmeš. Če ne pa pač ne.

Pri temu menim, da je nadležnost razdeljena na nadležnost za vzdrževalce in nadležnost za uporabnike. Slednja je recimo mnogo pomembnejša od prve, kar je tudi eden izmed razlogov, da še vedno ni množične uproabe digitalnih potrdil.

Bistri007 je izjavil:

Geslo na strežniku je shranjeno v md5(pw+salt). Prijava preko brskalnika poteka pa z md5([pw+salt]+oneTimeSalt), ki ga izračuna JavaScript.

Vidiš, znova si spregledal malenkost. Geslo ali ekvivalent gesla je še vedno mogoče zlorabiti. Če dobim seznam vseh MD5(pw+salt), potem nadomestim tvojo kodo, ki prebere geslo in izračuna ustrezen MD5(geslo + salt) s svojo kodo, ki v končno enačbo MD5(XXX, one-time-salt) vstavi ukraden XXX namesto izračunanega MD5.

Torej imam znova možnost izkoristiti pridobljeno bazo gesel (oziroma ekvivalentov gesel, kar tukaj ponavljam kot pokvarjena plošča) za zlorabo storitve.

Seveda. Ene kategorije nevarnosti si se izognil. Vendar pa si jih še vedno pustil dovolj odprtih, če že v izhodišču ne varuješ teh podatkov enako striktno, kot bi varoval čisto navadna plain text gesla.

Če želiš v splošnem pokriti tako ranljivost zlorabe gesel med spletnimi mesti in ranljivost zlorabe spletnega mesta po kraji seznama gesel ali njihovih ekvivalentov, se moraš tega lotiti ne z uporabo deljenih skrivnosti (shared secrets) ampak z uporabo tehnik asimetričnega šifriranja. Z nekaj razmisleka bi verjetno šlo... Recimo nekaj a-la "geslo -> RSA ključ" na strani odjemalca (lahko kar v JS), na strežniku pa je shranjen samo javni del ključa. Tako potem kraja teh javnih modulov tatu ne bi smela kaj dosti koristiti.


Vredno ogleda ...

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

Analiza slovenskih gesel

Oddelek: Novice / Zasebnost
395917 (3855) BlueRunner
»

Ranljivost na Flash medijskem strežniku slovenske vlade?

Oddelek: Novice / Varnost
162355 (1069) Pyr0Beast
»

Odstranjevanje uporabnika - XP

Oddelek: Operacijski sistemi
5815 (685) fosil
»

Kiberpipa vabi na...

Oddelek: Novice / Kiberpipa
92290 (1295) Mare2
»

Analiza ukradenih gesel: nič novega

Oddelek: Novice / Varnost
273718 (1605) CaqKa

Več podobnih tem