- Xiaomi 12T Pro - kétszínű, mint a kétszázas
- iPhone topik
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Milyen okostelefont vegyek?
- Honor 400 Pro - gép a képben
- iPhone 16e - ellenvetésem lenne
- Honor 200 - kétszázért pont jó lenne
- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Mobil flották
Új hozzászólás Aktív témák
-
válasz
#16820480
#123
üzenetére
Hat, ami kliens gepen van, azt alapbol necces megvedeni (pl. egy nagy cegnel eleve feltetelezheto, hogy jopar alkalmazott kompromittalodott, ergo akar le is videozhatja a kijelzot). De teny, hogy a G-nel is szurik a ceges gepeket, es a zero trust az a halozati oldalra vonatkozik elsosorban.
-
Mar irtam korabban, hogy a 'ceges halozat' elkepzeles a modern vallalati IT-ben egyre kevesbe elfogadott, abban az ertelemben, hogy a klasszikus iskola szerint
- legyen egy jol korulbastyazott ceges halo
- arra ne csatlakozhasson senki, csak menedzselt, ellenorzott vegpontok
- aki fent van a halon, az onnantol megbizhato
- tavolrol VPN-en keresztul jonnek be az userekA modern iskola azt mondja, hogy semelyik eszkoz nem megbizhato, ergo egy ceges szolgaltatasnak ugy kell kezelnie a klienseket mint potencialis tamado.
-
válasz
Tigerclaw
#95
üzenetére
Brainstormolni csoporttal sokkal-sokkal nehezebb videón keresztül, mint személyesen.
Annyira, hogy nálunk (full remote cég) mindenkinek el lett mondva, hogy ha a csapat igényli, kb. bármikor fizetjük a repülőjegyet, hotelt, konferenciatermet, ha személyesen szeretnének találkozni. Ritkán fordul elő, hogy kell, de akkor nagyon hasznos.
-
> leszarom hogy de legyen kész időre a kívánt minőségben
Sajnos ez nem működik akkor, ha menetközben változnak az igények vagy a meló rendes R&D.
Ergo ha van egy kozepesen kockazatos/bizonytalan fejlesztesi projekt, akkor hiaba mondod meg, hogy legyen kesz 3 honap mulva, ha harom het mulva kiderul valami sulyos technikai nehezseg, akkor ha megszakad a csapat sem tudja leszallitani idore.
-
válasz
#16820480
#51
üzenetére
Varj, most mi a threat vector? Nyilvan az SSL certifikatokat nem szabad figyelmen kivul hagynia a kliensnek. A MITM-el kapcs. itt talalsz infot:
If a man-in-the-middle (MITM) tries to intermediate between the user and the origin during the authentication process, the U2F device protocol can detect it in most situations.
Say a user has correctly registered a U2F device with an origin and later, a MITM on a different origin tries to intermediate the authentication. In this case, the user's U2F device won't even respond, since the MITM's (different) origin name will not match the Key Handle that the MITM is relaying from the actual origin. U2F can also be leveraged to detect more sophisticated MITM situations as we shall see below.
As one of the return values of the U2F 'sign' call, the browser returns an object which contains information about what the browser sees about the origin (we will call this the 'client data' object). This 'client data' includes:
- the random challenge sent by the origin,
- The origin host name seen by the browser for the web page making the javascript call,
- and[optionally] if the ChannelID extension to TLS is used, the connection's channelID public key.
The browser sends a hash of this 'client data' to the U2F device. In addition to the hash of the 'client data', as discussed earlier, the browser sends the hash of the origin and the Key Handle as additional inputs to the U2F device.
When the U2F device receives the client data hash, the origin hash and the Key Handle it proceeds as follows: If it had indeed issued that Key Handle for that origin the U2F device proceeds to issue a signature across the hashed 'client data' which were sent to it. This signature is returned back as another return value of the U2F 'sign' call.
The site's web page which made the U2F 'sign' call sends the return values -- both the 'client data' the signature back to the origin site (or equivalently, relying party). On receiving the 'client data' and the signature, the relying party's first step, of course, is to verify that the signature matches the data as verified by the user's origin-specific public key. Assuming this matches, the relying party can examine the 'client data' further to see if any MITM is present as follows:
- If 'client data' shows that an incorrect origin name was seen by the user
- an MITM is present
- (albeit a sophisticated MITM which had also intermediated the registration and thus got the Key Handle issued by the U2F device to match the MITM's own origin name, and the MITM is now trying to intermediate an authentication. As noted earlier, an MITM intermediating only at authentication time and not at registration would fail since the U2F device would refuse to sign due to origin mismatch with the Key Handle relayed from the original origin by the MITM).
- else if 'client data' shows a ChannelID OR origin used a ChannelID for the SSL connection:
- If ChannelID in 'client data' does not match the ChannelID the origin used, an MITM is present
- (albeit a very sophisticated MITM which possesses an actual valid SSL cert for the origin and is thus indistinguishable from an 'origin name' perspective)
It is still possible to MITM a user's authentication to a site if the MITM is
- able to get a server cert for the actual origin name issued by a valid CA, and
- ChannelIDs are NOT supported by the browser.
But this is quite a high bar.
An MITM case which the U2F device does NOT protect against is as follows: Consider an online service or website which accepts plain password but allows users to self-register and step up to U2F 2nd factor. An MITM with a different origin which is present between the user and the actual site from the time of registration can register the U2F device on to itself and not pass this registration to the actual origin, which would still see the user as just needing a password. Later, for authentications, the MITM can accept the U2F device and just do an authentication with password to the actual origin.
Assuming the user does not notice the wrong (different) origin in the URL, the user would think they are logging in to the actual origin with strong authentication and are thus very secure but in reality, they are actually being MITMed. -
válasz
#16820480
#42
üzenetére
Most fog igazan beutni egyebkent, h a Google-fele BeyondCorp-megkozelites mennyire kenyelmes. Ugye ok arra jottek ra, hogy a ceges VPN valojaban nem noveli a biztonsagot tulsagosan, hanem naluk kb. minden ceges szolgaltatas siman kint van az interneten (pl. [link] ), szoval igy barki dolgozhat barhonnan VPN-es szopas nelkul.
Foleg akkor jo, amikor egy kontinenssel arrebb dolgozol.
Új hozzászólás Aktív témák
Hirdetés
- BestBuy topik
- Revolut
- Kertészet, mezőgazdaság topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Autós topik
- Autóápolás, karbantartás, fényezés
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Philips LCD és LED TV-k
- Napelem
- További aktív témák...
- AKCIÓ! GAMER PC: Új RYZEN 5 4500-5600X +RTX 3060/3070/3080 +Új 16-64GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ
- UHH! HP EliteBook 840 G8 Fémházas Laptop 14" -45% i5-1145G7 4Mag 32/512 FHD IPS Intel Iris Xe Magyar
- Xiaomi Redmi Note 13 Pro 5G - 8/256 - Media Markt garancia
- Xiaomi Redmi 9at - 2/32 - szürke
- Xiaomi Mi8 - 6/128 - fekete
- OnePlus 13 - Black Eclipse - Használt, karcmentes
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7600X 32/64GB DDR5 RTX 5060Ti 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Szinte új, minőségi, állítható ritkítóolló
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RTX 4060 Ti 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest