Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Teorie je to hezká, ale dělal jste to někdy? Tohle právě (a další věci) řeší ty knihovny...Ano, dělal. Ty knihovny se z toho souboru snaží dělat objektový model, který je podobný objektovému modelu skutečného Excelu. Někdy je to zbytečný kanón na vrabce, protože se nepotřebujete zabývat všemi detaily dokumentu, pouze chcete data transformovat do jiného formátu nebo struktury.
Preco sa hned v prvej vete branis vpn (napr. openvpn) pre znaleho je to nastavovanie na par minut.Já jsem to pochopil tak, že se aigor.net nebrání VPN, ale že se ptá, zda to jde i bez VPN udělat přiměřeně bezpečné. Nakonfigurovat VPN na serveru je jednoduché, ale nemusí to být stejně jednoduché na všech klientech a v některých sítích může být problém protlačit VPN provoz – u SSH je přeci jen o něco pravděpodobnější, že projde, zvlášť když to chce mít na portu 443.
je to druha moznost, a lepsi s pouzitim 20mistneho Velke/male/cisla/znaky passphrase, nez mit ruzne klice s bez passphrase nebo s "Filip" ;-)Takže to není druhá možnost, ale třetí možnost – druhá možnost je ten váš vynález s žádným nebo slabým heslem. Jenže vy jste se tvářil, že to porovnáváte s tou první možností, tedy klíč chráněný silným heslem. Takže se znovu ptám – v čem je lepší vaše varianta „jeden klíč se silným heslem všude“ oproti variantě „unikátní klíč se silným heslem pro každého klienta“?
jak sem psal, prolomeni takove dukladne passphrase vyzaduje miliony superpocitacu s sanci v radu let, nebo tvuj domaci pocitac za ~trilion let ;-)To ovšem vycházíte z předpokladu, že se nenajde žádná chyba ani v algoritmu ani v programu a že nedojde k žádné neočekávané změně v používané technice. Což klidně za půl roku platit nemusí. Je zbytečné zvyšovat zabezpečení z milionu let na bilion, protože je velmi nepravděpodobné, že by zrovna tahle změna zastavila nějaký útok. Mnohem účinnější je přidat jinou vrstvu zabezpečení, která funguje na úplně jiném principu a nebude dotčena průlomem v té první vrstvě.
nerozporoval sem vyhodnost oddelenych klicu pro zarizeni, pouze zminil druhou moznost mit klic stejnej ale zabezpecenej passphrase (a ano logicky, silnou)...Možnost to je. Ale má ta možnost nějaké výhody?
puvodne si psal ze pri ztrate tabletu clovek nemusi rychle resit vymeny klicu, ted pises (kdyz sem upozornil na moznost silne passphrase ktere potrebuje miliony superpocitacu k rozlousknuti v radu let) ze za pul roku muze byt nalezena dira...Asi jste můj příspěvek nečetl úplně pozorně. Psal jsem o tom, že heslo by mělo být takové, aby ho útočník reálně zkoušel několik let. Počítám samozřejmě s nějakou rezervou, výkon se neustále zvyšuje, odhodlaný útočník si může pronajmout nějaký botnet s grafickými kartami nebo si to zaplatí v cloudu, takže počítám s teoretickou odolností toho hesla v řádu měsíců. Pokud se nenajde žádná chyba v implementaci. Takže mám několik měsíců na to dostat se k tomu notebooku – to mi připadá jako dostatečný čas. Ale zase pokud by k té ztrátě/krádeži skutečně došlo, nebudu tu rezervu několika měsíců využívat do poslední minuty (navíc se pohybuju v řádech, takže nedává smysl „řádově měsíce“ převádět na minuty), ale budu se snažit ten klíč (a třeba spárování s Google účtem a další) řešit bez zbytečného odkladu, v řádu hodin nebo maximálně jednotek dní. Tím opět získávám smysluplnou bezpečnostní rezervu.
jinak "tve" reseni ma take mouchu, kdyz mi ukradnou tablet a nebudu mit u sebe NB, nebo nekoho na telefonu, tak nemuzu na serveru zrusit ten ukradenej klic a s tvojim snadnym heslem mi ho nekdo rozlouskne driv nez se k NB dostanu
to je teorie, v praxi, kdyz pouzijes 20mistne passhrase s kombinaci male/velka pismena, cisla a specialni znaky, tak si zpocitej kolik milionu superpocitacu bys potreboval na rozlousknuti v radu let ;-)Já bych takové heslo v praxi na tabletu zadávat nechtěl. Nehledě na to, že bych příslušný klíč stejně v případě ztráty tabletu zablokoval, protože nechci myslet na to, že pokud by se třeba za půl roku našla díra ve způsobu, jak se s tím heslem nakládá, budu muset klíče vyměnit. Navíc nějak nevidím důvod, proč bych se měl bránit použití více klíčů – znamená to přidat jeden řádek do souboru s povolenými klíči.
nebo stejnej klic s passphrase, na tabletu (predpokladam Android) pouzivat ConnectBot v kterem pred pripojenim odemkne klic a po zavreni ConnectBoot je passhrase zapomenuta...Nikoli. Louskání hesla ke klíči může útočník dělat off-line, tedy může zkoušet hesla jak rychle chce a na jakém množství zařízení chce (resp. zaplatí). Heslo ke klíči tedy neslouží jako absolutní zabezpečení (typu „když mi ten tablet ukradnou, klidně ten klíč budu používat ještě za dva roky“), ale jenom vám dává čas příslušný klíč zablokovat. Rozumné heslo vám samozřejmě neposkytne pár sekund nebo minut, mělo by i odhodlaného útočníka zbrzdit minimálně na měsíce – bavíme se o bezpečnosti, takže je potřeba mít rezervu v řádech. I tak je lepší používat na každém klientovi jiný klíč, protože až k té ztrátě zařízení s klíčem dojde, nemusíte ve stresu všude vyměňovat klíče, ale prostě ten jeden klíč zablokujete (což samozřejmě předpokládá, že ty klíče máte pořádně označené a na serveru ten klíč snadno najdete). Postupy pro krizové situace by měly být co nejjednodušší – když vám někde ukradnou tablet, určitě budete řešit spoustu jiných věcí, než abyste se zabavoval generováním nových klíčů.
Ze začátku jsem se jakoby snažil mít zakazanyho roota a řešit všechno přes sudo, ale to je strašná ztráta času.Chápu, že se někde sudo používá pro potřeby auditu kdo co dělal, i když mi to připadá trochu zvláštní postup. Ale pokud je někde sudo nakonfigurované tak, že se dá spustit shell pod rootem, a má to sloužit k většímu zabezpečení, je to podle mne kontraproduktivní. Víc bych se bál chybné konfigurace sudo nebo chyby v sudo než toho, že někdo něco omylem spustí pod rootem a tím napáchá škody. sudo bych dál používal k tomu, k čemu bylo původně určeno – tedy ke spuštění vybraných aplikací s vyššími oprávněními. Pokud to daná aplikace ještě vyžaduje a nedá se to řešit např. přes capabilities.
Tak systém, který při změně hesla neresetuje všechny sessions daného uživatele bych nepovažoval za bezpečný.Ono nic jako session uživatele nemusí existovat. A i když existuje, autentizační systém nemusí být ten samý, jako systém poskytující služby – je to běžné ve webovém prostředí (weby i webové služby), třeba u OAuth nebo OpenID. Autentizační systém tedy vůbec nemusí vědět, jaké kde existují session. Třeba kdybych si teď na MojeID změnil heslo, nemá MojeID žádnou možnost, jak zjistit, že jsem zrovna přihlášený na diskusním fóru na Rootu, natož aby mne dokázalo odhlásit.
lepsi pouzivat Fetch API. Uz je podporovane ve vsech prohlizecich.
Profesor pri prednasce omylem napsal heslo do fieldu pro username. Videlo to 120 lidi v sale na platne. Tak si ho zkousel zmenit, ale nemohl, protoze si ho zmenil tesne pred prednaskou...Ještě by to chtělo, aby toho někdo opravdu zneužil, a aby za to zneužití byl potrestán „bezpečnostní expert“, který tohle pravidlo v dané instituci zavedl.
Jinak ten sleep uz by byl nepohodlny.... pri 12 ti heslech by se dostal zpet ke svemu puvodnimu za nejakych 6 - 7 hodin...Jen pokud by se potřeboval opakovaně přihlašovat. Často ale stačí se někam přihlásit jednou a pak můžete pracovat třeba celý den bez potřeby zadávat heslo znova. A do některých systémů se přihlašujete třeba jednou za několik týdnů nebo i měsíců – takže 7 hodin změny hesla vás opravdu netrápí.
A v mezicase by se musel vzdycky divat do toho scriptu jake ma aktualne heslo.
To uz je asi dostatecny opruz aby uzivatel radsi pouzival ruzna hesla...
Podle me jde jen o to, aby si ho nemohl zmenit na to puvodni.OK. Ne že bych to považoval za odůvodněné – kdyby někdo věnoval energii tomu, že si napíše skript, aby se dostal zpět na původní heslo, klidně do toho skriptu přidá i sleep(2000) – ale asi takhle někdo mohl uvažovat. Ale líbí se mi, jak tohle pravidlo jde už vyloženě proti bezpečnosti – když uživatel zjistí, že mu během změny hesla někdo stál za zády a heslo odkoukal, tak má prostě smůlu, to heslo půl hodiny nezmění, a „útočník“ si může s heslem dělat, co chce.
Nekde jde zmena hesla naskriptovat a potom by bylo jednoduche spustit tu zmenu ve smycce 12x.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.