Kontaktní formulář a GDPR

Najdeš to prakticky úplně všude. Pokud pracuješ - jakkoli, s reálnými daty uživatelů, máš povinnost je o tom informovat a získat od nich souhlas s jejich zpracováním, případně uložením. Zároveň by bylo fajn mít napsané GDPR informace - k čemu slouží, jak se ukládají, jak jsou zabezpečené atd.

Je to trošku složitější.
1) Pouze kontaktní formulář kde to někdo vyplní a tobě to jde na email. Nemusíš mít nic.
2) Pokud tyto údaje použiješ na nějakou členskou kartu ( vytiskneš, vyrazíš atd ) tak pouze necháš zaškrtnout "souhlas se zpracováním osobních údajů".
3) Když uložíš data do vlastní databáze nebo jiného seznamu dostupného z internetu ( je jedno jestli veřejně dostupný nebo jenom když by ti to někdo hacknul ) musíš uvést opět informovaný souhlas. viz. bod 2 ale ještě musíš uvést např. že data jsou šifrována a nejsou nikde veřejně. Např jako seznam členů.

4) Když tyto údaje poskytneš třetí straně např za účelem výroby členské karty tak musíš mít opět informovaný souhlas viz. bod 2 ale také uvést komu tyto údaje poskytuješ a proč.
5) Pokud data ukládáš a používáš i k jinému účelu než identifikaci ( např. hledání historie člověka, ověřování v rejstřících) tak by jsi měl mít na webu stránku která popisuje z hlediska GDPR jak a proč s údaji budeš nakládat a jak se postaráš o jejich zabezpečení.

Zde máš víc o GDPR kde najdeš vše. Je to docela sranda. Podle toho jak si to kdo vyloží, by jsi měl mít server zamčený v trezoru a odříznutý od sítí. :)

Už i když provozuješ web pouze na HTTP tak se na to nahlíží jako porušení GDPR o ochraně dat. Stejně jako na šifrování hesla pomocí MD5.

Podle toho kdo to napsal je na 100% pouze to když udaje vytiskneš, smažeš z počítače a vytištěný papír dáš do trezoru. :)

btw: nezapomeň na "sušenky" a informovat o tom na webu. :) To aby jsi se nenudil.

To bude tím že ten "chytrák" co to psal žije v době papírové. :)

Beru to dle mě dostupné metodiky vydané pro soudy a další státní instituce kterou mám vzhledem ke své práci k dispozici.

NoxOne:
Oceňuji fakty nabitou a komplexní odpověď, ale mám takovou možná rejpavou otázku. Řešil jsem v nedávné době něco podobného a prošel jsem pár konkurečních GDPR stránek a vidím to jako opakující se vzor - a i ve Tvé odpovědi se to vyskytuje.

„Stejně jako na šifrování hesla pomocí MD5.“

Všichni ve svých podmínkách píšou, že hesla jsou zašifrována. Z logiky toho, jak šifrování funguje, to znamená, že se dají rozšifrovat (pokud je někomu známý klíč). Hesla jsou v databázi typicky zahashovaná. Když zmiňuješ (a ostatní taky), že hesla šifrujou, je to kvůli tomu, jak je poskládané GDPR, nebo šifrování vs hashování je prostě jen úroveň detailu, kterou nikdo nerozlišuje?

Hash je podmnožina šifrování (jednosměrné šifrování).

Jednosměrné šifrování neexistuje. Šifrování z definice slouží k bezpečnému přenosu informace z bodu A do bodu B po nezabezpečeném kanále. Na druhé straně musí být způsob, jak tuto informaci obnovit.

mckay:
Odpověď na tvoji otázku je prostá. Ti kdo to píšou bezpečnosti nerozumějí. Pro ně jsou pojmy šifrování a hashování to samé. On ten výsledek vypadá vlastně podobně (není problém najít "experta" který ti řekne že base64 je šifra - vždyť se to nedá přečíst). Taky se v rámci bezpečnosti používají (na různých místech) obě metody. Takže spousta lidí má tyto pojmy za jedno a to samé a mylně je zaměňuje.

Omlouvám se za dezinformace.

Hash a šifrování jsou rozdílné věci. Hash rozlouskneš při znalosti klíče a tím získáš heslo (např. MD5). Při šifrování hesla znáš pouze otisk.

třeba u MD5 máš klíč a heslo. Pustíš na to MD5 a máš "šifrované heslo". Vezmeš tuto šifru a pustíš na ní správný software a on najde ten klíč ... a heureka ... máš i heslo.

u bezpečnějších metod je to tak že heslo se protáhne "šifrovacím strojem" kterému řekneš kolik znaků má mít klíč a samotné heslo. To vytvoří otisk a ten se uloží.
Když přijde uživatel tak zadá heslo a to se pošle na "ověřovací stroj" kterému řekneš počet znaků které má klíč. To vytvoří otisk vstupního hesla. Následně se porovnává ten otisk.

Ten otisk je ale stopa v čase a proto viditelně nejsou stejný.

např. otisk hesla v DB bude : $2y$10$jKs5hdvgGyOfrC9jdQEiBuOX90fdTYN6CJH8ehau2rJBF011X
otisk hesla ověření bude : $2y$10$q5MkhSBtlsJcNEVsYh64a.aCluzHnGog7TQAKVmQwO9C8xb.t89F

pro klasické porovnání == to nejde ale pro stroj s ověřováním je to heslo stejné.

Pokud jde o hesla na web tak mrkni na tohle a bude ti to jasný.

MD5 je pouze hash který se porovná.
např. heslo 123456 k němu dáš klíč a pustíš na to MD5 vyleze jkdfsgkvhndgkjn
uživatel zadá heslo a pomocí klíče vyleze jkdfsgkvhndgkjn to porovnáš klasicky "=="

záškodník ví že původní heslo bylo 123456 a z hacknuté DB bude mít hash jkdfsgkvhndgkjn
vezme script a řekne mu aby našel klíč k jkdfsgkvhndgkjn a že ví původní heslo 123456

to mu vrátí ten tvůj zadaný klíč. Ten použije na hesla získaná z DB ostatních uživatelů a už má jejich původní hesla.

Na webu je spoustu online dešifrátorů kteří ti při znalosti hesla a hashe za pár sekund vrátí i klíč. A také spoustu nástrojů kam vložíš hash a za pár minut ti vypadne seznam možných hesel v něm uložených.

NoxOne:
Tohle je tak špatně že to není jednoduché opravit. Na začátku to nejdříve vypadá že jsi jen omylem přehodil šifrování a hashování ale jak ten příspěvek pokračuje, tak je to jen horší a horší. Některé věci tam jsou tak trochu správně ale uvádět to celé na pravou míru se mi fakt nechce.

Reakce na NoxOne:
Mám pocit, že vím, co jsi chtěl popsat, ale tvůj příspěvek je tragicky špatně.

Při šifrování existuje klíč, při jehož znalosti je možné zašifrovaná data rozšifrovat. Při hashování nic takového neexistuje – vytváří se otisk, ze kterého nelze původní data získat. Hash je pro stejná data vždy stejný, když zahashuju nějaká data dnes, budou mít stejný hash i zítra.

Tebou zmíněná funkce password_hash řeší problém v tom skrytý – pokud bude mít deset uživatelů heslo abc, všech deset uživatelů bude mít stejný hash hesla. Když takovou databázi někdo ukradne, bude stačit, aby nějakým způsobem zjistil heslo jednoho z těch deseti, a protože hashe jsou stejné, bude jasné, že i hesla jsou stejná. (Pro častá hesla navíc existují i předpočítané tabulky s hashi.)

Bránit se dá použitím soli (salt). To je řetězec, který se k původnímu heslu přidá, a až z výsledného řetězce heslo + sůl se vypočítá hash. Sůl je náhodně generovaná a pokaždé jiná. To znamená, že ve výsledku bude mít deset uživatelů se stejným heslem různou sůl a tím pádem různý hash. Sůl není žádná důvěrná informace, v čitelné podobě si ji pro každého uživatele pamatujeme v databázi, abychom ji při přihlášení mohli opět přidat k zadanému heslu a vytvořit hash. Ten potom porovnáme s uloženým v databázi a pokud se shodují, uživatele přihlásíme.

Pro upřesnění. Z hashe se původní heslo se stoprocentní jistotou zjistit nedá. Dá se zjistit, zda by nějaký vstup odpovídal, ale nikdy si nemůžeme být jistí, že to je uživatelovo heslo. Ono totiž vstupů, které mají stejný hash je více*. Nicméně je pravdou, že v reálném případě to uživatelovo heslo bude, protože ostatní kolizní vstupy by si uživatel jako heslo nevybral. Z matematického pohledu to ale vyloučit nelze.


* Neplatilo by pro perfect hashing ale to používané hashovací funkce nejsou.

Asi jsem tím dotazem odvedl debatu úplně na jiné téma, ale děkuji všem zúčastněným za příspěvky. Myslím, že by se z toho všeho dal vytesat příspěvek do nějakého základu "FAQ (nejčastější dotazy) Bezpečnost" - něco podobného, jako má sekce PHP.

Dopustím se tedy lehké nekromancie a zkusím otevřít znovu téma, co jsem naťuknul zde. Poslední vyjádření moderátora (Kajmana, dokonce) bylo, že napíše-li někdo FAQ/Návod, je ochoten ho někam hodit. Napíšu první příspěvek na téma hashů, šifer a kódování a založíme tím sekci pro Bezpečnost? :)

Asi to neumím správně napsat.

password_hash je jenom odkaz. Co si to přečíst celé. Když 10 lidí bude mít heslo abc tak nebudou mít stejný hash protože použiješ další nastavení a jako sůl se přidává např. čas.
To si nastavíš v dalších nastaveních, také si určíš sílu "solení" počet přidaných znaků. A také způsob vytvoření hashe.

U MD5 to máš "heslo"+"sůl" a to pošleš na MD5. sůl musí být známá pro uložení hesla tak i pro ověření. Takže 100 lidí se stejným heslem abc bude mít stejnou sůl a stejný algoritmus a tím i stejné heslo.

Pro heslo používám sůl 15 znaků (ani já je neznám ) a říkám procesu že chci aby to bylo sha512 a nemám stejné řetězce.

Reakce na NoxOne:
„Když 10 lidí bude mít heslo abc tak nebudou mít stejný hash“
To ale pouze ve velmi specifickém případě – při použití funkce password_hash, protože hesla solí automaticky. Pokud vezmeš „čistou“ hashovací funkci (to je třeba rozlišovat) a neosolené heslo, tak pro 10 stejných hesel skutečně dostaneš 10 stejných hashů.

„To si nastavíš v dalších nastaveních“
Teď si nejsem jistý, jak moc specificky o PHP a password_hash se bavíme, ale jenom pro jistotu: nejlepší je žádné parametry ručně nenastavovat. Zvlášť pokud někdo kryptografii příliš nerozumí, tak hrozí riziko, že si nevědomky hashe oslabí.

„100 lidí se stejným heslem abc bude mít stejnou sůl a stejný algoritmus a tím i stejné heslo“
Sůl musí být pro každého uživatele jiná, jinak ztrácí svůj smysl.

„Pro heslo používám sůl 15 znaků (ani já je neznám )“
Sůl musíš znát, protože heslo při ověřování musíš osolit stejně, jako při prvním uložení hashe do databáze. Jinak ti nevyjde stejný hash a nebudeš moci správnost hesla ověřit.

NoxOne:
„Pro heslo používám sůl 15 znaků (ani já je neznám ) a říkám procesu že chci aby to bylo sha512 a nemám stejné řetězce.“
Ale znáš, jen o tom nevíš. Použitá sůl je uvedená ve výstupu.

Ano, to co máš je jasné ale u MD5 a podobných blbostí máš "sůl" v kódu u této metody není

$2y$10$aPOFQXyoOZzCuQPROzlaseRfKpXFwSLhTba4WDCtSrZ4Y9aSP//dW
$2y$10$GZxx4piLjrK9c5V1lTbsbeu.SkOoAVC7qOpR6PFi6hg4sztlOw3N2
$2y$10$9AHTHbXWvIgYO3VOGmrCNuw3BySnWUSol930RgTSu94skLIWjPwMe

vzor 3 hesel o délce 8 znaků. Vše protaženo skrze stejný skript. Podle tebe mají stejnou sůl.
Je vidět že si nerozumíme. U MD5 musíš mít sůl v kodu a tak je možné jí vždy vyčíst. Pokud by jsi měl sůl generovanou např. náhodných 10 znaků tak by jsi ji musel ukládat tak aby k ní byl přístup.

Většina lidí co používá MD5 tak má napevno v kódu sůl pro všechny stejnou. Když znáš sůl, původní heslo a hash tak jsi doma a přelouskáš i další hesla.

předpokládám že když to tak píšeš a máš znalost o:

algoritmu
sůl
hash

tak mi řekneš i ty tři hesla, použil jsem jednoduchý script s password_hash bez dalšího nastavení "PASSWORD_DEFAULT".

Ale nehádám se ... password_hash kdo nezná nenastavuje nic a přesto bude mít automatickou sůl a bezpečnost. Hesla ale nemůže porovnávat "==" protože hash je vždy jiný. Musí je porovnat pomocí password_verify .... který funguje tak že vezme uložený hash z něj vyjme dle nastavení (algoritmus, factor, sůl ) tím provede hash hesla a následně je porovná. Dělá se to tak právě proto že nikde není zapsaná sůl ( tak jako u MD5 ).

Stejně jako spousta lidí si myslí že "Hillova šifra" je super. Dnešní počítače mají takový výkon že není moc běžných šifer co se nedají rozlousknout. Proto osobně když je to možné na hash hesel používám HW klíče.

A to se bavíme o password_hash a password_verify bez dalších nastavení.

NoxOne:
„Pokud by jsi měl sůl generovanou např. náhodných 10 znaků tak by jsi ji musel ukládat tak aby k ní byl přístup.“
A to se taky běžně dělo. V databázi jsi měl sloupec s hashem a vedle toho sloupec se solí. Taky se to dalo obejít tím, že použiješ něco co je pro každého uživatele unikátní. Takže se dalo použít třeba md5($id.$password), md5($email.$password), md5($username.$password) a podobně. Samozřejmě tato zkratka pak vyžadovala, aby to co použiješ bylo neměnné, nebo pokud by se to měnilo, uživatel by si musel změnit heslo.
Pokud bys měl sůl konstantní, tak se tomu už neříkalo salt ale pepper. A ano, byly systémy co používaly salt+pepper+password.

mckay:
Takže jak jsi se ptal, proč tam mají v GDPR napsané jedno a přitom používají druhé, tak tady máš krásný příklad. Řekněme, že NoxOne o hashování a šifrování nějaké povědomí má. Přesto mu to nebrání termíny zaměňovat. A teď si vem, že ten text píše nějaký advokát, který o tom nemá ani páru.

Reakce na NoxOne:
„Vše protaženo skrze stejný skript. Podle tebe mají stejnou sůl.“
Keeehi v příspěvku výše napsal, kde přesně je v řetězci ukrytá sůl. Zcela zjevně je tedy při každém volání funkce password_hash jiná.

„U MD5 musíš mít sůl v kodu a tak je možné jí vždy vyčíst. Pokud by jsi měl sůl generovanou např. náhodných 10 znaků tak by jsi ji musel ukládat tak aby k ní byl přístup.“
Sůl musí být možné vyčíst vždy. Jinak nebude existovat způsob, jak ověřit, že se zadané heslo shoduje s původním. Výhoda password_hash je ta, že sůl přidá do řetězce s hashem (a password_verify ji od hashe zase oddělí), není tedy potřeba další databázový sloupec pro uložení soli. Ale je tam.

„Když znáš sůl, původní heslo a hash tak jsi doma a přelouskáš i další hesla.“
Ne. Pokud by byla sůl neměnná (nebo žádná), a znal bys heslo jednoho uživatele, dokázal bys zjistit, zda má jiný uživatel stejné heslo, protože by měl stejný hash. Pokud je sůl pro každého uživatele jiná, budou osolené hashe stejného hesla jiné. Pokud bude sůl neměnná a budeš znát jedno původní heslo, k prolomení dalších jiných hesel ti to pomůže (relativně) málo.

> předpokládám že když to tak píšeš a máš znalost o:
>
> algoritmu
> sůl
> hash
>
> tak mi řekneš i ty tři hesla
Pokud by šlo z těchto tří informací snadno zrekonstruovat původní heslo (nebo kolizní řetězec), byl by to skutečně mizerný hashovací algoritmus.

„Dělá se to tak právě proto že nikde není zapsaná sůl ( tak jako u MD5 ).“
Už jsem vysvětlil, kde přesně ta sůl zapsaná je. Navíc password_hash je funkce, MD5 je hashovací algoritmus. To je zásadní rozdíl, hashovací algoritmus vytvoří hash dat, které mu předáš. password_hash využívá hashovací algoritmy, kterým jako data předává původní heslo + sůl.

„osobně když je to možné na hash hesel používám HW klíče“
Hardwarové klíče se používají na něco jiného. Obsahují v sobě zabudovaný privátní klíč, který z nich nejde žádným způsobem ukrást (narozdíl od klíče uloženého na pevném disku). Slouží k vysoce bezpečné autentizaci a podpisu dat, nikoliv k hashování hesel.

Keeehi:
Právě jsi napsal to co jsem psal hned na začátku a proto GDPR a MD5 nejde dohromady.
U password_hash je to vše o nastavení. Dá se mu vnutit jako dodatečný klíč (sůl/pepř jak kdo chce) UUID systému pro větší bezpečnost ale zase nemůžeš hash/klíč/šifru jak kdo chcete přenášet na jiný stroj.

Firibix:
HW klíč si můžu použít na co chci a pro vyšší bezpečnost to také používám.

NoxOne:
„Právě jsi napsal to co jsem psal hned na začátku a proto GDPR a MD5 nejde dohromady.“
Kvůli čemu přesně nejde MD5 a GDPR dohromady?

„Dá se mu vnutit jako dodatečný klíč“
Toto je správně. Funkci se dá predat vlastní sůl, kterou má použít.

„UUID systému pro větší bezpečnost“
Nevím co přesně myslíš UUID systému. Ale je to jedno. Protože co je obsahem soli vůbec nemá vliv na bezpečnost za předpokladu že je jiná pro každého uživatele! Sůl 1 je stejně bezpečná jako sůl af3f473a-46a6-9eec-5ff928a8bb4ab. To že musí být jiná pro každého uživatele znamená že další uživatel může mít klidně 2. Pokud ty navrhuješ jak sůl použít pouze UUID nějakého stroje (nebo čeho to), tak bys tím tu bezpečnost naopak snížil. Pokud navrhuješ použít jako sůl UUID + něco unikátního pro každého uživatele, pak to má stejnou bezpečnost jako ta 1, 2, 3. Jen je to zbytečně větší voser.

„zase nemůžeš hash/klíč/šifru jak kdo chcete přenášet na jiný stroj.“
Můžeš. Ve výstupu funkce password_hash jsou veškeré informace které jsou nutné když budeš chtít ověřit heslo proti tomu hashi. Klidně můžeš na jednom stroji ten hash vygenerovat, hash poslat na jiný stroj a tam ověřit uživatelem zadané heslo oproti tomuto hashi.

„HW klíč si můžu použít na co chci a pro vyšší bezpečnost to také používám“
Ano, používáš. Ale ovšem asi vůbec netušíš co to dělá.

Mohl by to prosímmm někdo někam vyčlenit. Myslím že u ledu by to tomu docela slušelo. S původním tématem to má už pramálo společného a to uvádění NoxOneových omylů a nepřesností na pravou míru stejně nikomu nepomůže. Kdo tomu rozumí tak ví jak to je a kdo tomu nerozumí, tak toho to spíš asi jen zmate. No a pokud bude na to mít ještě někdo náladu, tam si můžeme v diskuzi pokračovat klidně do konce světa.

Kvůli čemu přesně nejde MD5 a GDPR dohromady?
MD5 je 128bit a to je dle GDPR málo.

UUID systému pro větší bezpečnost
jak jsem psal přidanou sůl ... hash má svojí generovanou sůl a UUID přidanou. Protože UUID se čte ze systému tak není možné heslo dešifrovat ani ověřit na jiném stroji. Nepíšu že UUID používám jako sůl ale přidanou sůl ( dle tvého je to pepř ) salt+pepper+password => generovaná salt+UUID+password. Tím dosáhneš hesel použitelných pouze na jednom počítači.

zase nemůžeš hash/klíč/šifru jak kdo chcete přenášet na jiný stroj.
Přenést nejde protože obsahuje UUID a to je jedinečné pro každý stroj ( pokud nemáš čínské desky kde někteří výrobci mají stejné UUID u milionů základních desek )

Ano, používáš. Ale ovšem asi vůbec netušíš co to dělá.
Vím co dělám. Pokud je HW klíč k dispozici tak jej použiji pro vložení přidané soli místo UUID.

NoxOne:
„MD5 je 128bit a to je dle GDPR málo.“
Skvělé. Kde se to prosím přesně v tom nařízení píše? Protože já nejsem schopen tam nikde žádné minimální nároky najít. Mám tak trochu pocit, že sis to vycucal z prstu. Tím samozřejmě neříkám, že je vhodné md5 na hashování hesel používat.

Když UUID (nebo cokoli) přidáš do soli, tak je úplně jedno, kde to generuješ a kde to pak ověříš. Řekněme že že hash vygeneruješ někde pomocí tohoto:
Vyjde ti z toho hash $2y$10$VVVJRCBzeXN0w6ltdSB4e.chhVERv0GCMhlrdRM.aS7evpDl7RvHq


A pak na jiném systému klidně můžeš udělat:

A bude tomu úplně jedno, jaké UUID bylo použité při generování toho hashe.

A mimochodem, od PHP 8 se už funkci password_hash vlastní sůl předat nedá. Naštěstí. Protože defaultně generovaná sůl bude v nejhorším případě stejně dobrá jako to co tam někdo ručně dá. Ovšem v rukou amaréra se to může maximálně jen zhoršit. Takže je dobře, že už to nebude možné.

Je to i v prováděcím předpisu. Chce si to přečíst celé tak jak to vydala EU výňatek z prováděcího předpisu:

Change Encryption Keys Regularly

Using one encryption key for a long period of time can expose you to a breach notification for historical data. Change your encryption keys on a quarterly or semi-annual basis. Alliance Key Manager can automatically change encryption keys at an interval you define.



Use Strong, Industry Standard Hash Algorithms

Use strong, industry standard secure hash algorithms when protecting passwords and other information. Never use MD5 or other weaker hash methods. Use the SHA-256 or SHA-512 methods for your hash requirements.



Use Keys or Salt with Your Hashes

When using a strong secure hash algorithm, always use an encryption key or random salt to strengthen the resulting hash value. You can use the Hashed Message Authentication Code (HMAC) method with an encryption key or use a strong encryption key under the protection of a key manager as the salt for the hash method. Alliance Key Manager can create, manage and protect the encryption keys for HMAC and salted hash operations.



A pak na jiném systému klidně můžeš udělat:

Ano máš pravdu při takovéto implementaci je to na nic.
Už jsem napsal kolegovi který má tyhle věci na starosti aby mi napsal přesný postup pro hash protože já to asi neumím podat.

NoxOne:
„Never use MD5 or other weaker hash methods.“
Ať hledám, jak hledám, tak tohle ve vyňatku co posíláš jediná zmínka MD5 a nemluví tam o bitech, to "weaker" může podle mě referovat na cokoliv (kolize?)

Ten vyňatek sám o sobě je ale taky zavádějící. V první větě sekce "use Strong, Industry Standard Hash Algorithms" říkají "Use strong, industry standard secure hash algorithms when protecting passwords and other information." A potom pokračují doporučením SHA-256/SHA-512 pro use case hashování.

Když by ty věty stály samy o sobě a nenaznačovala se mezi nimi spojitost, bylo by to jasný. Takhle to skoro ale vypadá jako doporučení hashovat hesla hash funkcema z rodiny SHA-X, což doufám, že reálné doporučení není.

Odkud tenhle text mimochodem pochází? Že tam všude v textu cpou komerční software, který s tím může pomoci. To se jako v takových oficiálních dokumentech smí? Tlačit konkrétní produkt nějaké konkrétní společnosti? :D

EU to asi tlačit může. Nevím. Dostaneme prováděcí předpis a jestli to uděláš dle svého a nebo nějakým komerčním způsobem je úplně jedno. Je to potom o někom kdo by musel komerční produkt pořídit. Prováděcí předpis najdeš na webu EU k GDPR. Dá to ale hledání pokud ti k tomu nedají přístup přímo. Je to stejné jako u naší vlády. Vydají nařízení/zákon který má nějaké "veřejné" znění. A k němu prováděcí předpis. Který by měl být veřejný. A také je ale vždy to tak zašijou že když k němu nemáš mít přístup tak dá hodně práce to najít.

Někteří šťouralové se potom snaží k tomu dostat podle §106/1999.