Byla vydána (𝕏) srpnová aktualizace aneb nová verze 1.104 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.104 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Spotify spustilo přehrávání v bezztrátové kvalitě. V předplatném Spotify Premium.
Spoluzakladatel a předseda správní rady americké softwarové společnosti Oracle Larry Ellison vystřídal spoluzakladatele automobilky Tesla a dalších firem Elona Muska na postu nejbohatšího člověka světa. Hodnota Ellisonova majetku díky dnešnímu prudkému posílení ceny akcií Oraclu odpoledne vykazovala nárůst o více než 100 miliard dolarů a dosáhla 393 miliard USD (zhruba 8,2 bilionu Kč). Hodnota Muskova majetku činila zhruba 385 miliard dolarů.
Bylo vydáno Eclipse IDE 2025-09 aneb Eclipse 4.37. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
T-Mobile od 15. září zpřístupňuje RCS (Rich Communication Services) zprávy i pro iPhone.
Společnost ARM představila platformu Arm Lumex s Arm C1 CPU Cluster a Arm Mali G1-Ultra GPU pro vlajkové chytré telefony a počítače nové generace.
Unicode Consortium, nezisková organizace koordinující rozvoj standardu Unicode, oznámila vydání Unicode 17.0. Přidáno bylo 4 803 nových znaků. Celkově jich je 159 801. Přibylo 7 nových Emoji.
Apple představil (YouTube) telefony iPhone 17 Pro a iPhone 17 Pro Max, iPhone 17 a iPhone Air, sluchátka AirPods Pro 3 a hodinky Watch Series 11, Watch SE 3 a Watch Ultra 3.
Realtimová strategie Warzone 2100 (Wikipedie) byla vydána ve verzi 4.6.0. Podrobný přehled novinek, změn a oprav v ChangeLogu na GitHubu. Nejnovější verzi Warzone 2100 lze již instalovat také ze Snapcraftu a Flathubu.
Polské vývojářské studio CD Projekt Red publikovalo na Printables.com 3D modely z počítačové hry Cyberpunk 2077.
Ahoj. Mám centrální aplikaci, která si v databázi ukládá uživatelské údaje - uživatelská jména, hesla, ... Tato aplikace pak podle potřeby vytváří účty ve spravovaných systémech a aktualizuje uživatelské údaje. Spravované systémy se občas připojí, zjistí si seznam úkolů (vytvoř účet, uprav, nastav heslo apod.) a ty lokálně provedou. Problém nastává, pokud se admin rozhodne, že chce daný účet přidat do dalšího spravovaného systému - pokud má centrální aplikace k dispozici jen hash hesla, pak musí vytvořit účet s náhodným heslem, uživatel se pak musí příhlásit k centrální aplikaci a heslo si manuálně nastavit. To se ukázalo jako docela komplikované a těžkopádné. Chtěl bych, aby centrální aplikace mohla nastavit do spravovaného systému heslo, které by měla k dispozici. Nechci ale ukládat hesla v plaintextu (pro případ jednorázového nabourání do db), proto přemýšlím, jak je šifrovat. Fungovat by to mělo nějak takto:
***** ****************** <---------------------- ******* admin ------------------------> centrální aplikace co mám dělat? systém1 ***** přidej pepu do systému1 ****************** -----------------------> ******* vytvoř účet pepa s heslem 123 centrální aplikace musí provést toto: 1. dešifrovat heslo pro pepa, toto heslo je uložené v její databázi 2. uložit si příkaz pro systém1, aby založil účet pepa s dešifrovaným heslem
Problém je bod 1. Napadlo mě následující řešení: mějme asymetrický klíč K1, symetrický K2. Pokud uživatel mění svoje heslo nebo admin vytváří nový účet v centrální aplikaci, pak toto heslo zašifrovat veřejnou částí K1. Admin pak toto heslo může dešifrovat privátní částí K1. Jenže adminů je více, proto by privátní část K1 byla šifrovaná klíčem K2. K2 by byl uložen několikrát v zašifrované podobě a dešifroval by ho každý admin vlastním heslem. To má výhodu tu, že klíč ani heslo nikdy neopustí server (pokud se zrovna nikde nepřidává do systému).
Jdu na to správně? Nebo neexistuje už nějaký algoritmus, jak toto řešit?
Řešení hodné třetího tisíciletí by bylo ověřovat uživatele pomocí asymetrické kryptografie. Pak bys nemusel řešit ukládání hesel, stačily by ti veřejné klíče uživatelů.Takové řešení by se mi líbilo, jenomže koncové systémy to neumí.
Zjevný problém tvého řešení je, že nabourám server, počkám si, až se nějaký admin přihlásí, poslechnu si K2, dešifruju K1 a dešifruju všechna hesla.Je to spíše veliká nepříjemnost, protože pokud se někdo nabourá na server, pak si bude stějně moci nastavit jakákoliv hesla komukoliv v jakémkoliv systému. Ono jde o to, jak se nabourá na server - pokud nepřevezme kontrolu nebo pokud ukradne "jen" zálohu někde uloženou, pak to toto šifrování řeší. Ještě by to šlo vylepšit dalším klíčem, který by měl k dispozici pouze admin, tzn. nejprve by v první fázi dešifroval admin, poté server => útočník by musel "bojovat na 2 frontách". Rád bych ale našel nějaké již vymyšlené řešení, abych nakonec znovu nevymýšlel kolo ...
Nejde v "systém1" vytvořit účet rovnou s tím hashem?Bohužel nejde.
nevim jestli jsem to pochopil spravne, ale neslo by to udelat tak ze budes mit aplikace jeden klic a ukladala by hesla v sifrovane podobe. a ped pouzitia
************** ****************
system ---------------------------> databaze
************** vytvor ucet pepa heslo aes(1234) ****************
pokud by system vedel klic k sifrovani hesla, mohlo by se heslo posilat do databaze jiz zasifrovane. A v pripade potreby muze aplikace pozadat o heslo a rozsifrovat si ho.
---------------------------------------------------------------------------------------------------------------------------------------
Dalsi moznosti je centralni databaze uzivatelu. U kterych bys mel ulozeno v kterych systemech jsou registrovani a v pripade potreby by jsi zmenil pouze tuto hodnotu
Pokud se ty systémy moc nemění a znáš všechny používané algoritmy pro hashování hesel, tak bys to mohl udělat tak, že jednotlivé systémy nebudou přijímat jen heslo v čistém tvaru, ale i hash. V centrální aplikaci pak budeš mít hashe ve všech možných tvarech (připravené pro jednotlivé systémy).
Druhá možnost je vložit mezi centrální aplikaci a každý systém novou komponentu, takovou černou skříňku, která poběží na samostatném stroji (nebo alespoň nějak rozumně oddělena) a bude spravovaná někým jiným než správcem centrální aplikace (třeba správcem daného systému) a bude mít svůj soukromý klíč. V centrální aplikaci pak budeš mít veřejné klíče jednotlivých skříněk a při vytváření hesla si to heslo zašifruješ všemi těmito klíči. Při nastavování hesla pak pošleš zašifrované heslo (kterému centrální aplikace nerozumí) do skříňky, ta ho dešifruje a heslo předá danému systému.
Nebo použij něco jiného než hesla – asymetrickou kryptografii, každý uživatel bude mít svůj soukromý a veřejný klíč, ať už SSH, X.509, GPG atd.
Tiskni
Sdílej: