Komentáře k článku

Neautorizovaný přístup k datům

V posledních dnech, týdnech a měsících jsem několikrát slyšel a četl o tom, že velkým hráčům unikla nějaká data, případně se někdo dostal k informacím, které vidět neměl, a to naprosto jednoduchým způsobem. „Útočník“ pouze změnil nějaké číslo v adrese stránky a v prohlížeči se mu najednou ukázaly údaje, k jejichž prohlížení nebyl autorizován. Jak je to jen možné?

Zpět na článek

51 komentářů k článku Neautorizovaný přístup k datům:

  1. M.

    Jak se bránit?

    Například před vrácením odpovědi kontrolovat, že je zalogován ten uživatel, který tu odpověď požaduje. Pokud to není on, tak vrátit login dialog…

  2. Rexxar

    User_id v kazdom dotaze je overkill

    Do kazdeho SQL query pridavat id pouzivatela je asi overkill. Prava pouzivatela staci overovat v metode controllera (MVC architektura), alebo niekde v uvode kodu.

    1. pb

      Re: User_id v kazdom dotaze je overkill

      Hmm, ale jak chcete ověřit práva uživatele? Asi takhle: Patří tohle číslo faktury, na které se tento uživatel ptá, tomu uživateli? Čili jedním SQL dotazem navíc?

      (Ikdyž nadruhou stranu, když předpokládáme normální workflow aplikace, tak aby uživatel kliknul na svou fakturu, musel před tím vidět seznam faktur, takže je máme v nějaké cache, takže by to spíš bylo: Dej mi všechny faktury toho uživatele (z cache), a z nich vyber tu hledanou).

  3. Rax

    To je staré

    Při práci s fakturami pro uživatele je skutečně nutné do každého dotazu vrazit where na ID uživatele a pokud možno ID uživatele vůbec neposílat na klienta, ale schovat ho třeba v session, jinak dochází přesně k tomu co je v článku. Překvapuje mě, že to v roce 2013 stále není všem jasné.

    1. Martin Hassman

      opakování taťka moudrosti

      Staré a osvědčené věci se musí opakovat znovu a znovu, jinak je další generace nepřijme a vymizí.

  4. Josef Vybíhal

    Re: Neautorizovaný přístup k datům

    Tímto trpěla samoobsluha Vodafonu pěkných pár měsíců. Člověk mohl měnit číslo v URL adrese a viděl přesně kolik Kč na které telefonní čislo bylo uhrazeno.

  5. Jakub Vrána

    Automatická kontrola

    Moje zkušenost je taková, že na co se dá zapomenout, na to se taky zapomene. Proto je důležité používat šablonovací systém s automatickým ošetřováním předávaných dat (jako obrana proti XSS, např. Nette Latte) a nějaký sestavovač dotazů, opět s automatickým ošetřováním dat (jako obrana proti SQL Injection, např. NotORM).

    Tenhle problém je k vyřešení těžší, ale napadají mě dva možné přístupy, jak mu systémově zabránit:

    1. Místo unikátního ID používat jako primární klíč dvojici (ID uživatele, pořadové číslo). Někdy to je žádoucí i z hlediska použitelnosti aplikace – např. místo příšerného Bug ID 3601407 na SourceForge.net dostanu hezké Issue #22 na GitHubu. V některých případech se hodí i globální identifikátor (např. číslo objednávky, aby se dala snadno identifikovat po telefonu), tam tohle řešení moc dobře použitelné není.
    2. K tabulce zakázat přístup na úrovni databázových práv a vytvořit uloženou proceduru get_order(user_id, id). V administraci, kde potřebuji přístup ke všem objednávkám, použijeme jiného databázového uživatele, který má přístup i k samotné tabulce. To neztrácí výhody globálního ID, ale je trochu těžší na nastavení a používání.

    Pak je tu samozřejmě ještě případ, kdy žádné ID uživatele nemám. Tam se dá aplikovat druhé řešení, jen místo user_id použijeme náhodný token. Použití GUID je v této situaci také možné, ale je potřeba dodat, že v jiných případech je spíš nevhodné. Inkrementace nebo hádání ID totiž není jediný způsob, jak se útočník může k datům dostat – ta můžou někde uniknout a pokud na jejich neuhodnutelnosti stavím zabezpečení, tak jde o pouhé Security by Obscurity.

    1. Rax

      Re: Automatická kontrola

      1. Primární klíč na fakturu je vždy ID z generátoru nebo autoincrementu a přes to nejede vlak. Navíc pořadové číslo faktury nelze u nové faktury před jejím commitem stanovit spolehlivě, proto ho nelze ani vrazit do primárního klíče a proto se faktury číslují dodatečně v druhém kroku.

      2. Do databáze chodí webový server celou dobu pod jedním uživatelem.

      Pro URL faktur lidí bez účtu se použije něco jako magic + údaje pro vyhledání faktury + salt dohromady 64 a víc byte to celé zašifrované solidním algoritmem se solidně dlouhým heslem + převod do tvaru vhodného pro URL. Bezpečnost je pak garantována kvalitou šifrovacího algoritmu a kvalitou hesla.
      GUID je možné také, ale to se pak musí někde ukládat a opečovávat.

      1. Jakub Vrána

        Re: Automatická kontrola

        2. Že je to takhle na většině hostingů, ještě neznamená, že to není možné.

        Cílem bylo navrhnout řešení, které by fungovalo automaticky, aniž bych na něco mohl zapomenout. Vámi popisované řešení je nejen zbytečně překomplikované, ale této podmínce se ani neblíží.

      2. china

        Re: Automatická kontrola

        2. bezpecnost na urovni databaze je zaklad kazde seriozni aplikace. To, ze cela aplikace pouziva jednu uroven opravneni se da jete akceptovat u nejakeho soukromeho webu, kam si pise majitel co mel zrovna k obedu ale u business critical aplikaci je to naprosto neakceptovatelne.

  6. Cermi

    HMAC

    Proč tak složitě? Já osobně jsem pro takové věci implementoval „kontrolní“ hash pomocí nějaké HMAC funkce (hashovací fce s klíčem), který se hodil do URL v mailu. Má to tu výhodu, že to umožňuje i anonymní požadavky (ve smyslu objednávky), což někdy může zákazník chtít.

    1. Rax

      Re: HMAC

      Protože kreativita útočníků je vskutku neuvěřitelná a čím méně toho ví, tím lépe.
      Samozřejmě na jednoduchý webshop jde HMAC použít také.

  7. Karel

    Userid když neexistují uživatelé

    Nejjednodušší je opravdu dotazy psát stylem „where orderno = .. and userid = …“ nebo „where orderno = … and user_authorized(­…)“. Přičemž to userid zná jen server, v URL se neobjevuje. Server si ho může zapamatovat buď při přihlášení uživatele, nebo ho může vygenerovat při „přihlášení uživatele“. V uvozovkách je proces, kdy uživatel na serveru vlastně žádný účet nemá. V tomto procesu si server vygeneruje dvojici – userid a randomid. Do databáze si uložím tuto dvojici, na klienta jako cookie předám randomid (nebo bude součástí url). Když se pak někdo dotáže, tak já si přeložím randomid na userid a dotaz provedu. Jakmile dojdu k názoru, že už se na to podívat nesmí, tak jen smažu záznam z překladové tabulky, takže už nikdo ani „správné“ userid nepodvrhne.

    K přístupu k „cizím datům“ je tedy potřeba znát číslo objednávky a randomid. Randomid má jen omezenou časovou platnost (např. datum dodání + 1 den) a navíc může být (narozdíl od čísla objednávky) skutečně náhodné. V případě potřeby se k němu dá přidat něco dalšího, co není snadné podvrhnout – například IP adresu. I v systému, kde se uživatelé neregistrují, tak není problém zabránit cizím lidem si číst data. Problém je ovšem v tom, že si pak ta data po čase nepřečte ani původní objednatel. To je ale daň za anonymitu.

  8. greeny

    Což takhle...

    Napadá mě řešení – každá objednávka dostane ID, které je unikátní pouze pro daného uživatele – může např. existovat více objednávek č. 3.

    Je to jen malinko upravené, ale pomůže to taky…

  9. Michal

    nikdo neslyšel o ACL?

    To si děláte srandu že http://www.damejidlo.cz nepoužívá nějaké ACL, ne? IMHO se bez objektového ACL větší tohoto typu aplikace neobejde. Vždyť je na to i tutoriál v Nette pro začátečníky.

    1. roman

      Re: nikdo neslyšel o ACL?

      Si robite srandu, ze sa autorizacia bez objektov neda naprogramovat?
      Ale pokial je tam Nette ok :)

  10. Petr

    Nautorizovaný přistup k datům DameJidlo

    Rád bych tady pod článkem ještě jednou poděkoval panu Průšovi za report chyby. Chyba byla na základě jeho podnětu opravena.

  11. Opravdový odborník :-)

    Odborný názor

    „Hausnumera“ a GUID jsou jen obskurnost, která neřeší primární problém — uhodnout GUID je sice těžší než uhodnout vzestupně rostoucí ID, ale problém je jinde – v tom, že útočník na základě znalosti nějakého ID obdrží data, která obdržet nemá. Navíc je to systémové špatné řešení, protože míchá dohromady dvě věci: identifikaci objektu a autorizaci uživatele resp. řízení přístupu k obejktu. Je to asi jako kdybyste na disku schovali data do souboru, jehož název nikdo nezná (nebo si to alespoň myslíte). Chyba. Správné řešení je použít příkaz „chmod“ – jednoduché a čisté.

    Vložení UID do podmínky v SQL dotazu je naopak dobrá cesta – nepotřebná data se do aplikace ani nedostanou a nelze je zneužít. Má to ale jednu nevýhodu: nelze rozlišit, zda objekt neexistuje nebo zda k němu jen uživatel nemá práva. Většinou je to v pořádku, protože ošklivému útočníkovi nepotřebujeme sdělovat, zda trefil ID objektu nebo ne. Ale někdy je to na škodu – uživatel potřebuje vědět, že nemá práva, aby si o ně mohl zažádat a nebyl zmatený/vyděšený z toho, že daný objekt neexistuje.

    Používání databázových procedur však nijak nepomůže. Uložené procedury jsou sice užitečné a jsem pro jejich používání, ale tento problém neřeší – je implementační detail, jestli tohle vyřešíme na úrovni aplikace nebo databáze – zapomenout na kontrolu je možné na obou místech. Stejně je potřeba ošetřit případy, kdy data nežádá běžný uživatel, ale správce nebo systémová úloha.

    1. Rax

      Re: Odborný názor

      A kam si opravdový odborník schová UID pro objednávky vytvořené ad-hoc, tedy uživatel nemá účet, když se mu Hausnumera a GUID nelíbí ?

      1. Opravdový odborník :-)

        Re: Odborný názor

        Každý uživatel má účet resp. záznam v naší databázi, i když třeba nezná svoje heslo. Je zbytečné (a nebezpečné) vytvářet nějakou alternativní cestu pro přístup k datům pro neregistrované uživatele.

          1. Opravdový odborník :-)

            Re: Odborný názor

            To byste si měl jít někam dostudovat, když to nevíte. Ale budu tak hodný a řeknu vám to.

            Uživatel bude už přihlášený (relace v prohlížeči – cookies) nebo se přihlásí pomocí jednorázového tokenu (ano, „hausnumero“), nicméně tento token slouží k přihlášení, nikoli k identifikaci objektu (např. objednávky).

            Tyto dvě činnosti (přihlášení uživatele vs. identifikaci objektu) je potřeba oddělit (byť to můžou být dva parametry v témže HTTP požadavku, nicméně jsou na sobě nezávislé).

            1. Rax

              Re: Odborný názor

              No já to právě vím, proto čekám co z vás vypadne a vypadlo hausnumero :-)
              Problém přihlašování hausnumerem je identický jako problém zobrazování faktury přes hausnumero. Pravděpodobnost uhodnutí 32-bit id faktury + 64-bit hausnumera je +- stejná jako pravděpodobnost uhodnutí 96-bit hausnumera přímo na fakturu.

              1. Opravdový odborník :-)

                Re: Odborný názor

                1) „hausnumero“ není jediná ani první možnost, o které jsem psal.

                2) O uhodnutelnost tu vůbec nejde (v obou případech je potřeba použít kvalitní generátor náhodných čísel a dostatečně dlouhé číslo, aby to bylo o několik řádů výš, než co se dá „uhodnout“). O co tu jde je vnitřní složitost aplikace – přístupová práva ověřujeme jednotně (podle aktuálně přihlášeného uživatele) a nevznikají nám tu alternativní větve a dodatečná složitost způsobená tím, že bychom za určitých okolností (přítomnost hausnumera) ověřovala přístupová práva jinak. Kromě toho až příště bude potřeba povolit přístup k jiné entitě, bude se nám duplikovat kód i data. Může to být další objednávka téhož uživatele se třeba bude chtít podívat nejen na fakturu, ale i na objednávku – nakonec to dopadne tak, že datový model bude zaneřáděný a v každé tabulce bude nějaký sloupeček s „hausnumerem“ – místo abychom evidovali jen ID uživatele a tokeny měli jednoduše na jednom místě napojené na uživatele. Proto jsem psal, že je dobré oddělit autentizaci/au­torizaci od identifikátorů objektů.

                1. Rax

                  Re: Odborný názor

                  Tomu rozumím, mě celou dobu jenom zajímalo jak jste to dokázal bez hausnumer a tedy jenom jste převedl hausnumero z objednávky na usera a říkáte tomu token.

                  Problém s eliminací zaneřádění datového modelu řeší můj příspěvek z 23.1. 12:22, tokeny ani hausnumera vůbec není třeba do DB ukládat.

                  1. Opravdový odborník :-)

                    Re: Odborný názor

                    Použití kryptografie (v tomto případě spíš hashování než šifrování) může být elegantní (ale i zrádně nebezpečné, pokud se to udělá špatně), ale pořád to neřešít ten problém, že máme více způsobů, jak ověřit práva uživatele k objektu. Z architektonického hlediska mi to přijde špatně a zbytečná složitost – v prvním kroku bych „přihlásil“ uživatele (to může být víc způsobu – klasické jméno/heslo nebo token nebo ještě něco jiného) a v dalším kroku ověřoval práva a dělal všechny ostatní věci (už vždy stejným způsobem – jednotně – bez ohledu na to, jak se uživatel přihlásil). Další věc, na kterou jste zapomněl, je, že je dobré umět spárovat různé objekty patřící jednomu uživateli (více objednávek, více faktur, otázky odeslané přes kontaktní formulář, dotazy ve fóru atd. – vše je dobré mít propojené a evidovat tu entitu „uživatel“).

      2. j

        Re: Odborný názor

        Zeby mel uzivatel trebas session ID co? A ze bych trebas tu session overoval pri praci s tim, co zrovna tvori, co? Nejaky IDcka v linku sou naprosto nezajimavy.

  12. Jan

    Náhodný hash

    Čo je zlé na metóde kde url je v tvare: /detail-objednavky/?hash=sha­1(uniqid(micro­time(), true)) ?
    (za predpokladu že každá objednávka má stĺpec s náhodným hashom, ktorý je unique)

    Pravdepodobnosť že by niekto uhádol 40 miestny kód je velmi malá, netreba žiadne id užívateľa (len málo užívatelov si v obchode vytvorí účet).

    1. expert

      Re: Náhodný hash

      Mas poneti, jak funguje hashovani? Pak bys nenapsal takovou blbost. I sebelepsi hash je tak bezpecny, jak nahodny (velky) je jeho vstup.

      Predpokladat, ze se bezpecnost zvysi, kdyz ze vstupu ‚xmvkfdkl‘ hashovanim vypocitam vystup ‚csdckliovjev­jioajdsasnkjas­vnjk‘ je samozrejme blbost.

      Hash ma smysl jen tehdy, je-li definicni obor mnozina vetsi nez mnozina oboru hodnot hashovaci funkce. Je zrejme, ze uniqid(microtime(), true) negeneruje vetsi mnozinu nez sha1(uniqid(mi­crotime(), true)).

  13. janpoboril

    Frameworky

    Tady se dobře projevilo, že psát si aplikace na koleně (bez frameworku) je bezpečnostní hazard. Třeba v Drupalu je to jen o konfiguraci, všude pak hlídá, jestli uživatel má oprávnění k stahovanému souboru přistupovat.

      1. janpoboril

        Re: Frameworky

        Tak by ten framework měl být odkázán na to, že ho bude používat na složitější aplikace jen pár šílenců (WordPress, Joomla :-)).

        Žijeme ale v realitě, kde kvalita ne vždy vítězí a tak musí vycházet tyto články. :-)

    1. Honza

      Re: Frameworky

      Aha, takže vy říkáte „je hazard, abych zabezpečení dělal já, je lepší se spolehnout na framwork“. Čili vy zabezpečení nerozumíte a neumíte to, tak tam radší dáte framework, protože ten to má vyřešené.
      Jestli to berete takhle, tak je největší hazard, abyste na to vůbec sahal, protože slepým nabastlením frameworku lidmi, kteří tomu vůbec nerozumí, vznikají nejhorší paskvily.

      Framework je dobrý sluha, ale zlý pán – pokud mu rozumíte a víte přesně, co dělá, tak je správné ho využít, protože vám ušetří práci. Pokud je ale framework chytřejší než vy, tak ho nepoužívejte, protože ho použijete špatně a výsledek bude (ne)fungovat úplně jinak než si představujete.

    2. j

      Re: Frameworky

      Jiste, framework vyresi bezpecnost sam od sebe … lol … tohle muze psat opravdu leda mamlas. Framework vyresi proste podle vyjadrovani nekterych tady uplne vsechno … a proto mame tisice frameworkovych webu a miliony der v nich.

    3. Michal ŠpačekAutor příspěvku

      Re: Frameworky

      DámeJídlo používá framework, konkrétně Nette. V článku přesně na toto téma jsem napsal:

      Použití jakéhokoliv nástroje, ať už je to webový framework nebo bouchač z reálného světa s východním přízvukem automaticky nezaručí bezpečnost vašich webových aplikací, nezávisle na tom, co tvrdí autor daného nástroje. Nebo váš nejlepší kamarád. Nebo váš šéf. Vždy se naučte, jak daný nástroj pracuje, jaké má omezení, jaké vlastnosti a kdy je vhodné jej použít a kdy ne. Vše pečlivě otestujte a hlavně věřte pouze svému úsudku a svojí hlavě. Tedy pokud nějakou máte.

      A to se vztahuje i na frameworky.

  14. Karel

    zlobivy googl

    K te bezpecnosti spousta vyvojaru si verzuje sve scripty bohuzel ne uplne chytre napriklad radi pouzivaji neco.php.bak nebo cislovani, na tom by nebylo nic zleho kdyzby upravily htaccess, protoze se mi parkrat stalo ze sem na podobne stranky narazil kdyz sem neco hledal v googlu.
    Googl mi takto jednou hezky ukazal zdrojovy kod jednoho eshopu. A co sem nevidel diru v sql, a ma temna strana se taktez probrala k zivotu, netrvalo dlouho a sesmolil sem asi 30znakovy text, vlozil jej do inputu pro zaslani hesla na email, a zachvyli mi server poslal vypis vsech svych uzivatelu vcetne hesel.

    1. j

      Re: zlobivy googl

      Zdrojak v principu ale neni problem, problem je prece ta dira, a na tu by se dalo prijit i bez nej, i kdyz mozna by to trvalo, ze … ostatne, v pripade php a spol (tedy interpretovanych jazyku) s tim clovek proste musi pocitat. Nemusi to byt chyba v nastaveni, staci kdyz nekde neco z nejakeho duvodu zbuchne … a to muze dycinky.

    2. koudy

      Re: zlobivy googl

      V dobe GITu a podobnych udelatek mi prijde kazdy, kdo si dela verzovaci system zpusobem file.0.1.1.bak jako blazen!
      Vzdyt staci mit 2 adresare – 1 testovaci a jeden „produkcni“.
      Ani to nemusite zalohovat, ale predpokladam, ze budete mit git na serveru (kvuli testovani) a u sebe na pracovni pc/ntb a mate rovnou i „zalohu“.

      1. Opravdový odborník :-)

        Re: zlobivy googl

        Mít verzovací systém na serveru je jen o trošku menší bastl. Je to použitelné maximálně tak při vývoji/testování (v rámci vývoje, ne AT). Pro seriózní práci se používají balíčky, které se na server nasadí/nainstalují.

  15. maio

    Validace || Repository

    Pouzivam 2 pristupy:

    1. Validuji vstupy – a to nejen, ze ID je cislo, ale i to jestli je validni pro prihlaseneho uzivatele. Je to o 1 query navic, kazdopadne z hlediska performance to nestoji temer nic. Vetsim problemem je, jak uz bylo zmineno, ze na to muze clovek zapomenout.

    2. Nepouzivam primo SQL dotazy, ale dotazuji se objektu. Takze pokud chci treba objednavku ID 123 tak napisu $orders->query->where(„id = ?“, 123) s tim, ze $orders je treba OrdersForUser(‚fran­ta‘) a metoda getQuery zajisti, ze tam bude pokazde i where(„user = ?“, „franta“). Pak se nemuze nikdy stat, ze vratim neco spatne – staci pohlidat, ze $orders je spravne skonstruovan, ale to je temer jistota, protoze se to deje jen na 1 miste v cele aplikaci.

  16. juzna

    Na čí straně je chyba a jak to vysvětlit normálním lidem

    Přijde mi nesmyslné, že je trestné změnit si číslo v URL a dostat se tak k cizím datům. Pokud má někdo nést odpovědnost za to, že takto někdo neoprávněně získal data, tak by to měl být snad provozovatel aplikace / webu. Nezabezpečil totiž pořádně data jemu svěřená.

    Díky tomuto článku by se snad i laická veřejnost mohla dozvědět, že ono slavné hackování není žádná magie a super extra nelegální činnost, ale že je to ve skutečnosti úplně jednoduché.

    1. https://tomasfejfar.mojeid.cz/#bLGPpVT97A

      Re: Na čí straně je chyba a jak to vysvětlit normálním lidem

      Je to trestné ze stejného důvodu, jako je trestné ukrást odemčené auto. To, že to jde snadno neznamená, že by to nemělo být trestné.

      1. Flašinet

        Re: Na čí straně je chyba a jak to vysvětlit normálním lidem

        Tady je ale zcela odlišná „obvyklá praxe“. Zatímco auta nebývají volně k dispozici pro kolemjdoucí, u informací na Internetu je to naopak zcela běžné.

        1. Jenda

          Re: Na čí straně je chyba a jak to vysvětlit normálním lidem

          Vy opravdu nejste schopen poznat, jestli v případě DámeJídlo ta data pro vás byla nebo ne?

      2. juzna

        Re: Na čí straně je chyba a jak to vysvětlit normálním lidem

        Když bych přijel na parkoviště, dal hlídačovi klíče a on mi odpověděl: „Vaše auto jsme zaparkovali na místě 133“. Já bych pak přišel a řekl: „Mám auto na místě 134 a on mi to auto dal“. A ještě bych dodal „a pak mám taky auta na místech 135, 136, 137, …“

        1. Jenda

          Re: Na čí straně je chyba a jak to vysvětlit normálním lidem

          Ano, i toto by bylo trestné (pro vás a nejspíš i pro toho hlídače).

  17. JeanSolPartre

    chybí mi ještě 2 patra

    Když chceme zajistit autorizovaný přístup k datům jen dotyčnému uživateli
    1.uživatel je bezpečně autorizovaný, to tu nepadlo, chtěl bych si napsat javascript generátor jednorázových hesel, poprvé se pošlou hashe, pak se už stále pozná že jis tem, za kterého se vydáváš.
    2. uživatel vidí virtuálnmí tabulky s právy SELECT a INSERT (nikoli UPDATE a DELETE)
    3. má k nim systémový p

    Dělám eshopy a můj framework osCommerce používá kombinace sessions_id a tokenu. Mě to zatím stačilo (když jsem zhruba ve stejné době jako autoři OSC pochopil že je třeba mít token aby se sessions nekradly) a soustředil jsem se na dvě další patra.

    – zámek na úrovni řádků databáze, který tady mezi jinými okrajově zmínil Jabub Vrána
    pomocí view, ve kterém se uživateli založenému pro zákazníka filtrují do virtuální tabulky jeho data), možná že Jakub Vrána to dělá chytřeji, já pro jistotu zakládám nového uživalte, která má neuhodnutelné nejen heslo ale i username, kdyby se zase v MySQL objevil podobný bug jako když bylo možné heslo známéhjo uživalele uhodnout… )

    – citlivá data jsou zašifrována Vernamovou šifrou (znak po znaku je transponován náhodným řetězcem, matematicky neprolomitlené) k rozšifrování dojde po autorizaci každého požadavku zvlášť a rošifrované data jsou klienetem po přečtení smazána.

    Tohle všecho mi více-méně funguje za cenu zatím obvykle nooo až několikahodinové konfigurace … trápí mně ještě problém vstupní autentizace, aby byla softwarová a dvoufaktorová, třeba skvencí jednorázových hesel…

  18. JeanSolPartre

    shrnuti problemu autentizace

    1.uživatel je BEZPECNE autorizovaný
    2. uživatel ma prava jen k virtualnim tabulkam
    3. citliva data jsou zasifrovana

    ad 3. Ja jeste resim, ze fozsifrovani rozhoduje pro kazdy jednotlivy SQL dotaz samostatny crypt server jako nezavisla instance, ktera se rozhoden, jestli je pozadavek na rozsifrovani duveryhodny a nebo podvrzeny.

  19. antiamík

    Takže je možné, že i vy, moji milí čtenáři, tento zákon právě porušujete.
    – Nikoho tady nemusí nějakej amíckej zákon zajímat, takže to je absurdní tvrzení.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3771