Vysvětlovat adminům, že trvat na hesle s milionem různých paznaků je blbost je stejně marné jako vysvětlovat (ve své době) že zmáčknutí Ctrl+Alt+Del před loginem do Windows opravdu bezpečnost nijak NEzvyšuje. Navíc v dnešní době především webových služeb nikdo nedělá brute-force úroky protože po 5. pokusu ho web zabanuje. Jediné na čem bych trval je délka hesla a šmitec. Naprosto stačí heslo "mujpejsekalik". Ale to některým omezencům prostě nevysvětlíte. Snažil jsem se ve firmě argumentovat i studiemi z univerzit kolem hesel ale to je jak házet perly sviním. Admin si někde přečte že "nejlepší je komplexní heslo" a nehnete s ním ani párem volů.
Ctrl+Alt+Del vyvolá přerušení, takže to dokáže zachytit jen OS a ne běžné aplikace. Takže si můžete být jist, že po stisknutí Ctrl+Alt+Del zadáváte přihlašovací údaje do okna OS, a ne do okna, ktereé vám namalovala nějaká podvodná aplikace (a které „shodou okolností“ vypadá úplně stejně, jako přihlašovací dialog).
Omezení na počet chybných přihlášení na webu je perfektní nástroj, jak někomu zablokovat účet. Útočník ani nemusí nic řešit, nástroj pro DoS mu naservírujete na stříbrném podnose.
To vůbec nevadí, ono může být dost nepříjemné i dočasné zablokování. Třeba zrovna dneska před půlnocí bude spousta lidí odesílat přes datové schránky daňová přiznání. Když se ve 23:50 dozví, že jejich přihlašovací údaje byly na 30 zablokovány kvůli opakovaným pokusům o přihlášení chybným heslem, radost rozhodně mít nebudou.
Neurážejte prosím adminy. Admin je povětšinou rozumný člověk, který by si taky nejraději zvolil jedno pro něj jednoduché a jinak obecně špatně rozlousknutelné heslo, a to heslo by měl nafurt. Ten, který je tím kokotem na prameni, je většinou bezpečák. To je ten, který si něco přečetl a dělá z pozice moci chytrého.
nejlepsi je www.keepass.info aplikace
staci znat par hesel a vse ostatni mit ulozeno v teto app. vstup do app je na heslo ale muzete pouzit i heslo + soubor napr. obrazek.
app hesla i muze generovat dle zadaneho vzoru.
To sice není špatná metoda, ale naprosto zcestná. Pokud už potřebujete k přihlášení nějaký nástroj, ten nástroj by neměl obsahovat hesla, ale kryptografické klíče o dostatečné délce. Heslo + soubor jsou směšné prvky zabezpečení. Co myslíte, že běžný uživatel bude mít za heslo a obrázek? Aničku a fotku Aničky. Pokud ho zadává často, bude ho mít přepřipravený, nebo v oblíbených. Čímž se stává veškerý přínos imaginárním.
Zkrátka pokud potřebujete k přihlášení nástroj, měl by umět to nejlepší z průmyslových standardů. Ostatní je jenom droboučký krůček vpřed.
Před (hodně) lety unikla hesla (ne hashe, ale opravdu hesla) z nějaké tehdy populární slovenské služby a hacker to zveřejnil, určitě by to šlo ještě někde dohledat. Bylo pěkné si to číst. Vesměs něco jako jméno "zuzana", heslo "zuzicka" atd. Byla by docela zajímavá programátorská úloha napsat nad tím kompresi na míru nebo případně hádačku hesel při známém jménu. Půlka by byla tréninková množina a druhá půlka testovací. Docela by mě zajímal počet pokusů vítěze na průměrné heslo, podle mě by to nebylo víc než 10 :-)
Myslím, že tento komiks celkem přesně vystihuje míru složitosti hesel: https://xkcd.com/936/
niektori ludia maju velke problemy zapamatat si heslo (zopar uctovniciek v jednej firme) a stupidna firemna politika vyzadovala heslo ktore splnalo security policy.
riesenie je velmi jednoduche:
na monitore ma nalepku s retazcom 'X3*b12Z' a okrem toho si pamata slovo napriklad 'chladnicka',
vysledne heslo ktore si posklada je 'X3chladnicka*b12Z'
Otázka bezpečnosti je vždy mít co nejvíc překážek pro potencionálního útočníka. Pokud se mu nevyplatí louskat hesla, znamená to, že část s hesly je vyřešená poměrně dobře. Problém tohoto přístupu je, že lidská blbost je nekonečná a uživatele nikdo nechce poučovat, z jakých důvodů na jejich hesle záleží. A zároveň uživatelé nechtějí být poučování, akorát to zdržuje...
Váš přece netrápí, že se někdo vloupe do vašeho bytu a tam pak louskne heslo do password manageru. Váš trápí, že někdo ukradne hashe hesel ze spatne zabezpečeného serveru, aniž by si toho někdo všimnul. Chcete-li, považujte zamknute dveře za prvek hybridní vicestupnove autentizace.
Ono by mnohem jednodussi bylo nevyzadovat login ke kazdemu nesmyslu. Nac je kuprikladu nejake heslo k diskusnimu webu? Nac je heslo do hry? Mam kolem 50 hesel jen do ruznych online her ktere jsem kdy zkousel. K cemu je to dobre? K nicemu. Dalsi desitky, nebo spise stovky hesel mam na vsemozne weby. Nac? Velmi casto pak to "bezpecne" heslo muze mit jen ascii alfanumericke znaky, nesmi byt delsi nez ... kuprikladu 6 znaku (zdravime microsoft, ti to maji vylepsene o to, ze tam klidne muze uzivatel zadat 50 znaku, ale realne se pouzije prvnich 6)
Sluzby, kde ma nejaka autentizace smysl bych spocital na prstech jedne ruky.
Proc? Mam sem napsat post jako VfB? Stane se neco katastrofickeho? Nejaky duvod? Zadny neexistuje.
Co uzivateli brani si registrovat extra ucet pro kazdy prispevek? Nic, a bezne to take nekteri delaji. Email? Existuji desitky sluzeb kde lze registrovat jednorazovy mail. A stovky a tisice freemailu, kde si kazdy muze registrovat mailu kolik chce.
Ty tisice webu ktere vyzaduji free registraci jsou jednim z primarnich duvodu proc lide vsude pouzivaji stale totez jmeno a heslo. Velmi rychle pak prestanou rozlisovat mezi sluzbou, kde o nejake zabezpeceni realne jde, a sluzbou, kde na tom nesejde.
takže tvrdíš, že jsi 100% zabezpečený a přitom svěřuješ veškerá svoje data nějaké společnosti (že by usaip.eu?)...
VPN ti zabrání pouze odposlechnutí komunikace, ale když budeš mít breberku přímo na počítači, které ti odposlechne hesla z prohlížeče, je to k ničemu ;).
V tom případě, bys ještě na VPN serveru musel zakázat komunikaci s jinou sítí než s tou bankovní, v tom případě, by breberky sice posbíraly hesla, ale neměly by je jak poslat. To samozřejmě znamená, že se na jiné stránky než bankovní nedostaneš :)
VPN je vlastně totéž jako HTTPS. Jejich úkolem je šifrovat komunikaci tak, aby někdo po cestě tu komunikaci (heslo) nezachytil.
Jenže to je pouze ochrana při komunikaci. Už neřeší problém na výchozím nebo cílovém místě. Na klientu může být keylogger, který zachytí pomoci stisku kláves ono heslo. Na serveru může být slabina, která umožní útočníkovi vybrat databázi. V těchto situací skutečně VPN nepomůže.
"Sůl bývá uložena v databázi s hashi..." Jistě, ale pokud se sloupec přímo nejmenuje "sůl", jak útočník pozná, který ze sloupců ze všech možných tabulek v databázi je používán jako sůl? Co když někdo používá jako sůl odpověď na kontrolní otázku nebo část emailové adresy a podobně... Někdy se spolu s heslem pro vytváření HASHe spojuje heslo a jméno nebo heslo a jméno a příjmení... Útočník by se musel dostat ke zdrojovému kódu stránek, který už nemusí být tak snadno dosažitelný a teprve pak by mohl zjistit jak je HASH tvořen... Nezná-li útočník algoritmus vytváření zdroje textu pro HASH má velmi malou šanci zjistit patřičný HASH...
Tohle je jen varianta security through obscurity. Bezpečnost, kterou lze nějak významně posílit tím, že algoritmus bude tajný, je iluzorní. V ideálním případě se bezpečnost malinko zvýší; v realistickým případech se zhorší.
Utajení soli neřeší žádný problém, který by neřešila už dostatečně dlouhá sůl.
Príklad OpenSource webová apka, kde je algoritnus výpoštu odtlačku verejný. Ak má jednu časť reťazca soli uloženú v súbore, zabráni to prieniku v prípade, ak útočník dumpne databázu. Bude na úspešné prelomenie systému bude okrem úniku databázy potrebovať ešte úspešný útok na súborový systém, čo je ďalšia prekážka. Podľa mňa to význam má.
Utajenie soli tiež priamo znemožňuje útok hrubou silou na databázu hashov. Alebo chcete tvrdiť, že je rovnako náročné lámať databázu md5 hesiel, ako md5 hesiel osolených 50 znakovou soľov ak nepoznáte algoritnus solenia? Napríklad: md5( left(salt,35) . heslo . right(salt,15)) );
Alebo ak algoritmus poznáte, ale nepoznáte tú 50 znakovú soľ?
Tajit algoritmus výpočtu hashe je naprostý nesmysl. Už ve druhé světové si ověřili, že důležitý není na enigmě. Důležité a zásadní je tajit data k algoritmu - klíče.
Už několikrát jsem narazil na podobnou pseudo bezpečnost, kterou tu předkládáte. Salt MUSÍ být generovaný náhodně ke každému heslu. Salt nesmí být pevně uložený v jednom souboru a stejný pro všechna hesla, jinak je jeho bezpečnost relativně slabá.
Pokud už vám někdo dumpne databázi, máte velký problém. Řešit to přidaným saltem je možné, ale zabezpečení tohoto je spíš virtuální. Prostě musíte zabránit dumpnutí databáze, při možnosti číst nebo modifikovat databázi beztak útočník může dělat všechno, aniž by potřeboval se přihlašovat.
Nicméně pokud by salt byl statický, stačí vám zlomit z celé databáze jediné heslo. Což není tak nemožné, určitě najdete alespoň jednoho uživatele s velmi slabým heslem. Dál už víte, že stejné části jsou všude stejné. Takže jediné, co to zabezpečí, je první hash na prolomení.
Jediný smysl to dává v případě, že máte jeden saltc v konfiguraci v souboru. Potom máte saltu, který je pro každého uživatele vygenerovaný náhodně. A teprve kombinací těhle dvou solí s heslem získáte něco použitelného. Tím vaším způsobem rozhodně ne. A vážně nehraje roli, jestli přidáte kus na začátek a kus na konec, akorát to ztěžuje chápání algoritmu.
Podle mne je nejdůležitější vůbec nikdy nepředávat hesla v otevřeném tvaru nebo jeho ekvivalentu serveru. Technicky je to triviální, prakticky tomu brání jen chybějící standardy. Evidentně totiž bezpečnost zajímá jen hrstku lidí, ostatní místo ní řeší obezličky typu solení hesel.
Na straně provozovatele je pak druhou nejdůležitější věcí to, aby se útočník nedostal k databázi.
Solení hesel je jenom taková obezlička pro případ, kdy není splněn první odstavec a nepodaří se zabránit druhému. Při „kvalitě“ dnešních webových aplikací ať radši každý hesla hashuje a solí, ale je dobré mít na mysli, že to není žádné zásadní bezpečnostní opatření, ale nouzová záplata jednoho detailu v případě, kdy je ta aplikace děravá jak řešeto.
Nech sa páči, pmocou bling SQL injection na webe ste sa dostali s hashom:
0a01c923e9989d65e0e64f0eec8ce589
29e705f646c9b8d47676fd79f838d48b
Prezradím Vám, že heslo má 7 znakov, len nalé veľké písmená a číslice. Slovníkovému útoku ani hrubej sile prvý hash neodolá. Druhý odolá.
Prvý hash je neosolený, druhý osolený saltom, ktorý nie je v databáze a nemôžete ho dupmnúť pomocou zraniteľnosti, ktorou ste sa dostali k hashom (Blind SQL Injection).
Ukážte mi, že to nemá zmysel a prelomte to, bez použitia toho prvého hashu aj druhé heslo, ktorého zložitosť je rovnaká:
713b276e7fb3793ba833804fdb319f7a
;-) prajem príjemnú zábavu.
<cite>
Ještě k tomu saltu. Pokud si v databázi vytvoříte svůj účet s heslem, které znáte, zjistit, jak ho zamíchali před hashováním nebude příliš složité.
</cite>
OK, pre Vaše heslo Petr je hash takýto:
73605cd42b4f96f0d33dc35cf20c4861
poprosím si heslo k hashu:
713b276e7fb3793ba833804fdb319f7a
;-)
Algoritmus poznáte. Je použitý nevhodný alrogitmus s md5.
Ukážte mi prosím, čo je podľa Vás "nie príliš zložité".
Pořád to nechápete. Já nejsem útočník, který myslí nabourání se do vašeho systému vážně. Řešíte, jak těžké je lámání hashů hesel. Jak už napsal Filip, problém zde neleží. Problém leží v tom, že se vůbec k těm hashům dostanete, a pravděpodobně nejen k nim. Dostanete se k soukromé komunikaci, emailům, časům přihlášení. Jako autor musíte chránit celou databázi, nikoliv jen plaintext hesla. Hash je jenom záchranná brzda, ale při děravé aplikaci to nevytrhne sebelepší fligna. Když jsem se dostal k databázi, proč spoléháte na to, že do obsahu souborů se dostat nedokážu? Pokud to dokážu, váše zlepšováky jsou k ničemu. Prostě CELÝ systém musí odolávat napadení, nejen uložení hesla. Trávíte čas detaily, které žádnou speciální bezpečnost neposkytují. Přitom se nezabýváte tím, kde máte jiné díry. Bezpečnost není jen otázkou hesla, je to komplexní problém. Pokud jsem schopen zblbnout vrstvu, která z plaintextu vyrábí ten váš superbezpečný hash, je celé vaše snažení pro smích. Pokud zbytek funguje dobře, zase jenom zdržuje generování hashů.
Ja to chápem veľmi dobre, nechápete ma Vy. Je mi jasné, kde je problém a čo ako autor webovej apky musím robiť a ako. V tom sa absolútne zhodneme.
Ja sa ale bavím o tom, že ak už hashe z databázy niekto dostane, najčastejšie a typicky zneužitím bling SQL injection, salt v súbore zabráni napriek diere v apke prelomeniu účtu. To je celé a preto tvrdím, že nápad s hashom mimo databázu nie je úplná blbosť ako tvrdíte. Zo skúseností s útokmi to hodnotím ako nie zlý nápad. Nejde tu totiž len o kód ktorý máte vy ako autor pod kontrolou. Berme ako príklad nejaký modulárny syustém, kde si na Vámi vytvorenú a dobre zabezpečenú aplikáciu žívateľ nainštaluje deravý modul vlastný alebo tretej strany, ktorý má SQL Injection. Tým že v takomto systéme použijete ten hash mimo databázy, zabránite úspešnému vedeniu útoku na Váš systém, cez deravý modul tretej strany. Toto je dosť častý scenár, nie nejaká fantazmagória. Nebavme sa o tom, že primárne je chyba v tom deravom module s SQL injection, ktorý by deravý byť nemal. To je bez debaty. Bavme sa o tom, že aj v takomto prípade máte ako autor aplikácie možnosť ako zabrániť úspešnému vedeniu útoku ak pri chybe v module tretej strany.
Nemusíme sa tu baviť o tom, čo bude ak sa útočník dostane k súborom na úrovni filesystému, pretože to už nepotrebuje nič. Má absolútnu kontrolu nad aplikáciou a dostane sa k službe aj bez lámania hashu, heslá si kľudne odchytí pri logovaní userov a pošle si ich, nepotrebuje už nič lámať, zmení si priamo výkonné scripty.
Potrebujete nakopnúť?
http://www.root.cz/clanky/tunely-v-hasovacich-funkcich-kolize-md5-do-minuty/
Určite sa to pre md5 dá, ale zas tak úplne triviálne a jednoduché to nebude… ;-) a ak by som miesto md5 použil sha512 tak môžete snívať…
Můžete mi objasnit tu část o statické soli a rozlousknutí jediného slabého hesla? Konkrétní příklad: Mějme uživatele zuzanka s velmi slabým heslem zuzanka. Hashovací algoritmus je md5( left(salt,35) . heslo . right(salt,15)) a pro zuzanku je hash 0c0e48fc7192656605208fc06d01c03d. A teď mi řekněte heslo uživatele s hashem fc70749842b417eb45a91f02026cdfa1.
Máte sice pravdu, že v případě statické soli stačí rozlousknout jediné heslo, jenže to nespočívá ani tak v uhodnutí toho hesla jako v uhodnutí té padesátiznakové soli. A tu už si nemusí nikdo pamatovat, takže je to náhodný řetězec, omezíme-li se jen na alfanumerické znaky, dělá to nějakých 4E89 kandidátů. Přeju hodně štěstí a trpělivosti.
Problém statické soli je, že pro různé uživatele se stejným heslem vrací stejný hash, takže když rozlousknete heslo zuzanka (třeba tak, že předtím, než ukradnete databázi hashů, si uživatele s takovým heslem založíte), víte, kdo všechno toto heslo použil. Ale o jiných heslech Vám to fakt nic neřekne.
V diky bezne dostupne karte GeForce GTX 980 hadame cca 10 248 milionu hesel za sekundu - 10Gh/s . v ramci MD5
pri utoku na WPA je to 190430H/s ..
Postavili jsme s drobnou investici pole 15 techto grafickych karet.. .. Vykon je 154 Ghs .. pri crackovani MD5 prolomime 10 mistne heslo pomerne rychle..
MD5 na tom samozrejme bezne nelouskame . do 9 znaku pro SHA1 a MD5 mame komplexni rainbowtables..
brutalnejsi je vykon pri crackovani WPA/WPA2 pouzivane u WiFI ..
2 857 kh/s .. libovlne 9 znakove heslo na wifi se prolomi do 24 hodin.. naklad na provoz je cca 85W co grafika.. Nakup grafik se nam vratil ve dvou bezpecnostnich analyzach..
Je to dnes jiz nutna vec v ramci bezpecnostnich testu a dalsich analyz.. Planujeme porizen jeste 50ks grafickych karet..
Se vykonem ktery poskytuji graficke karty v dnesni dobe se da s malou farmou uspesne atakovat kupa veci, sifer, algorimtu vsude okolo kam se jenom podivate.
Pokudli nekdo utoci na hash obsahujici heslo da se to v hodne pripadech resit bez bruteforce
Anička55 - slovnikovy utok 1 sekunda
AničkaVomáčková55 - slovnikovy+rule attack - 15 sekund
AničkaAničkaAnička - slovnikovy+rule attack - 10 sekund
AničkaAničkaakčinA - slovnikovy+rule attack - 25 sekund
Můžu se zeptat, kolik má takový slovník přibližně slov?
Když vezmu třeba to AničkaVomáčková55, tak to patrně znamená vyzkoušení všech dvojic slovníkových slov. Teď úplně plácnu, že slovník pro češtinu bude mít třeba 200000 slov. (to jsem viděl u nějakého anglicko-českého slovníku) Prakticky to bude asi mnohem víc. Pak by to znamenalo 4x10^10 kombinací. A čísla na konci to ještě zvednou o dva řády. A pokud budou čísla rozmístěna jinak, tak to bude ještě podstatně víc. Moc se mi nezdá, že by to šlo za 15 s.
Skúste pozrieť napríklad na toto: http://www.insidepro.com/
Má to slovníky + definované pravidlá, pomocou ktorých potom vytvára kombinácie.
dneska je heslo pomalu i na klíče od hajzlu, kdejakej pižďuch v tom nejposlednějším webshopu nebo žvanivé diskusi vás nutí k povinné registraci - nepochybně to vede buď k tomu, že máte všude stejné heslo (= špatně), nebo heslo genericky odvozené od webu (= obzvlášť špatně), nebo máte u complu válet papír se seznamem super neuhodnutelných hesel (= úplně špatně).
přitom kdyby někdo to vaše heslo skutečně potřeboval, a váš admin byl skutečně paranoidní a super dobrý - nejjednodušší je hacknout server poskytovatele, nebo vám přiložit pistoli k hlavě.
hnus, marnost, a beznaděj.
Jak chcete bez přihlášení na eShopu ověřovat zákazníka a zároveň provozovat nějaký věrnostní program nebo jinak se zákazníkem pracovat. Rychlá objednávka, kdy vám pracovník eShopu zavolá na číslo uvedené v objednávce je sice příjemná pro zákazníka ale už méně pro ten eShop a pokud budete v konkrétním eShopu nakupovat častěji, tak bude registrace plusem i pro vás jako zákazníka.
A u diskuzního fóra chcete autentizaci uživatelů bez registrace zajistit jak?
váš text je sám odpovědí.
fakt si myslíte, že je někdo zvědavej na to, že vy ho chcete ověřovat a s ním "pracovat"? kdyby byla registrace plusem pro zákazníka, nebylo by nutné ho k tomu nutit, ne? kdo chce věrnostní program, může se zaregistrovat třeba i v tesku a u schellky. tam aspoň stačí mávnout kartou, a nikdo ho nenutí vymýšlet jednašedesáté heslo.
co asi taková alza nebo mall dělají lépe než vy, že dokážou něco prodat i bez povinné registrace? aha, už vím. dělají prodej příjemně pro zákazníka, a svou potřebu příjemných požitků získávají raději z tržeb. tupci.
a co dělá lupa blbě, že tady žvaníte bez povinné registrace? neděsí vás, že nejste "autentizován"? vítej na zemi, potvůrko podivná - nebolelo to moc, spadnout sem až z mlhovin andromedy?
Já u Mall.cz registraci používám, protože pak mám historii objednávek, seznam faktur, snazší reklamaci, nákupní seznamy. Co je na zeleném skřetovi příjemného netuším, já ho považuji naopak za velmi nepříjemného a sám o sobě stačí k tomu, abych na Alze nenakupoval.
V diskusích na Lupě mi připadá pozoruhodná korelace, že diskutující s hodnotnými komentáři nemají problém se registrovat. Pokud by všechny komentáře nepřihlášených uživatelů zmizely, neměl bych pocit, že jsem o něco přišel.
to uz se tu (a jinde) take resilo milionkrat... Filp Jirsak muze klidne byt Jirina Voprsalkova
mohl by to byt ponekud usmevny pokus jak si zajistit legalizaci vlastnich bleptu ne? udelat si profil :)
spis by to vedlo k vetsi konformnosti prispevku a mnohdy zajimave nekonformni odpovedi by se tu casto neobjevovaly
spis bych tyto nez tisickrat "podepsaneho" Filipa Jirsaka (neni to mineno osobne, ale proste jste tu napsal toho a tak to odnasite I za jine)
Copak na tom jméně záleží? Nezáleží, záleží na identitě. Sice nikde není zaručeno, že jeden člověk nebude mít více účtů, ale je docela slušná pravděpodobnost, že za jedním účtem se bude skrývat jenom jeden člověk. Takže tak trochu víte, s kým máte tu čest. Když napíše, že je něco černé, a v dalším komentáři, že je to bílé, oprávněně můžete tvrdit, že si protiřečí. Když jeden komentář napíše nepřihlášený „sdfsdfsd“ a další komentář nepřihlášený „sdfsdfsdf“, netuším, jestli je to ten samý člověk nebo ne. V takovém případě se dá celkem dobře trollovat nebo vést flamewar, ale kloudná diskuse se vést nedá.
Nepsal jsem, že všichni uživatelé s účty píšou jen hodnotné komentáře. Takže založení účtu rozhodně nic nelegalizuje.
Rád bych viděl ty zajímavé nekonformní komentáře nepřihlášených uživatelů. Řekl bych, že převážná většina z nich budou uživatelé, kteří tu jinak účet mají, ale z nějakého důvodu se nemohli přihlásit. A taky bych rád viděl jediný komentář někoho, kdo by v případě povinného přihlašování ten komentář nenapsal.
aha, pán je expert.
vy potřebujete registraci u mall, abyste dokázal najít jejich objednávky a faktury - a mně neregistrovanému, mall tohle posílá mejlem (nejdřív ověření objednávky a pak fakturu k témuž) a najdu si to v poště takový tým čudlíkem na kterym je napsáno "search" (to znamená šorži hledej, víte?).
a když si jako registrovaný stáhnete z webu mall.cz ten reklamační list, vy to pdf-ko dostanete už předvyplněné svými registrovanými údaji? jůůůů, tak to já nemám .... mne se stáhne jen formulář, který navíc musim vytisknout a vyplnit ručně, scheisse!
no a "hodnotný komentář", to je taky rétorická perla. ve které správě jste pracoval v dobách temna? hodnotil hodnotnost hudby, nebo textu, nebo dokonce divadla? nebo si hrál s kačenkou na dvorku?
To je fajn, že vám vyhovuje vyhledávání v e-mailu - to ale neznamená, že mně nemůže vyhovovat mít přehled všech objednávek z jednoho e-shopu na jednom místě.
Jako registrovaný uživatel (v jiném e-shopu) nestahuju z webu žádný reklamační list v PDF, ale vyplním reklamaci přímo na jejich webu a můžu pak i sledovat její stav.
Pro mne je hodnotný komentář takový komentář, který má nějakou hodnotu, např. jsem se z něj dozvěděl něco užitečného. Pokud pro vás jsou všechny komentáře stejné, je to váš problém. Například z vašeho komentáře je nejpodstatnější to, že věci rád překrucujete, a to pro mne opravdu žádnou hodnotu nemá.
Nemusí, a také to nechce každý e-shop. Když to nějaký chce, nemusíte tam nakupovat. Myslím, že je dost e-shopů, kde můžete nakupovat bez registrace.
Mně mnohem víc vadí, že si to každý e-shop řeší po svém, musím tam mít extra přihlašovací údaje a extra heslo – obchodů, které by akceptovaly třeba OpenID je málo. A hlavně se obávám, že bitvu o globální poskytovatele identity vyhrávají sociální v čele s Facebookem.
Vidét jsem přednášku slovenského exp.na videu s Bratislavy a nabyl jsem dojmu, že lze obejít vše a zrušim interbankin.Přesto se chci zeptat na dvoufázový ověřování na Googlu, kde se píše,že zločinec by vám musel fyzicky ukrást mobilní telefon aby se dostal do účtu. Děkuji ek
Dvoufázové ověřování znamená, že se identita uživatele ověří dvěma nezávislými způsoby. Nejčastěji se používá dvojice uživatelské heslo (které si uživatel pamatuje nebo ho má někde bezpečně poznamenané) a jednorázové heslo (které vygeneruje nějaké uživatelovo zařízení, nebo ho dostane na zadávání prvního hesla nezávislým kanálem - třeba SMS). Pokud jednorázová hesla generujete v mobilu, musel by tedy útočník jednak získat vaše heslo, a jednak nějak vypáčit to jednorázové heslo z mobilu.
Vychází se z toho, že i když se útočníkovi podaří třeba získat kontrolu nad vaším počítačem a odposlechnout heslo, je pro něj těžké zároveň ještě napadnout váš mobil. A proto se útočníci zaměření třeba na internetové bankovnictví (kde se právě dvoufaktorová autentizace používá) snaží uživatele PC přesvědčit, aby na mobil nainstaloval jimi připravenou aplikaci - aby měli přístup k oběma částem ověřování.
Z toho důvodu také není bezpečné používat internetové bankovnictví na tom mobilu, na který vám chodí případné ověřovací SMS. Protože pokud útočník získá kontrolu nad vaším mobilem, kontroluje oba dva kanály - může třeba v příkazu k úhradě nahradit účet za svůj, a až vám přijde potvrzovací SMS, nahradí v ní číslo účtu zpět. Takže vy nic nepoznáte, ale potvrdíte transakci na jiné číslo účtu, než si myslíte.
Ale pokud dvoufaktorovou autentizaci používáte bezpečně, je to velice dobrý způsob zabezpečení a internetové bankovnictví bych nerušil. Myslím, že je to o dost bezpečnější, než příkazy k úhradě chráněné pouze vaším podpisem namalovaným na papíře.