’touch me’ – nieoczywista oczywistość

czemu tokeny FIDO chcą żeby je dotknąć?

ktoś zadał mi takie pytanie i w sumie ja też sobie je kiedyś zadawałem…

kiedyś

jako dinozaur, bardziej naturalnym [czy też tradycyjnym] sposobem uwierzytelnienia są dla mnie karty karty inteligentne. nie do końca rozumiem, czemu nigdy nie zdobyły popularności na rynku małych i średnich firm oraz prywatnie:

  • są super tanie!! pojedyncza karta to koszt ok. $1-2
  • łatwo dostępna technologia – przez długi czas dużo laptopów wychodziło z wbudowanymi czytnikami
  • fajnie integrowały się z systemami bezpieczeństwa dostępu fizycznego – ta sama karta do bramki przy wejściu i potem odpowiednie poziomy dostępu do pomieszczeń.
  • ta sama karta do logowania do systemu co do drzwi

taki klasyczny 'żarcik edukacyjny’ w niektórych firmach w jakich pracowałem, to szybka podmiana pulpitu na jakieś złośliwe zdjęcie, albo wysłanie maila do całego teamu 'stawiam wszystkim pączki!’, kiedy ktoś odszedł od kompa nie blokując pulpitu… dodatkowa zaleta smartcard jest taka, że kiedy osoba odchodzi od komputera – np. do toalety – musi użyć tej samej karty, a wyjmując ją z kompa automatycznie blokowana jest stacja.

a jednak to tokeny FIDO2, ze wszystkimi swoimi wadami, od ceny zaczynając, rozpychają się na obecnym rynku…

dodatkowo przez jakiś czas zastanawiałem się po co trzeba je dotknąć? spodziewałem się że to małe coś na tokenach, to czytnik linii papilarnych – to by miało sens. ale nie – to zwykłe zwarcie jest. niektóre 'nowoczesne’ modele są tak zaprojektowane, żeby były malutkie i 'nie przeszkadzały’ podobnie do nadajników radiowych, i żeby nie trzeba było ich w ogóle wyciągać – a więc co to za zabezpieczenie? to tak jakby zostawiać klucz w zamku – wystarczy przyjść i przekręcić.

odpowiedź

odpowiedź jest prosta – te klucze nie mają chronić przed próbą dostępu fizycznego. konieczność dotyku powoduje, że przy próbie uwierzytelnienia zdalnego, kiedy wymagany jest 2FA, potencjalny atakujący nie będzie w stanie go użyć… bo jest zdalnie, czyli nie może dotknąć tokenu. statystycznie patrząc, nie bronimy się raczej przed kolegami z pracy, dość rzadkim scenariuszem są również sytuacje, w których atakujący ma fizyczny dostęp do naszego komputera.

dodatkowo, bardziej prawidłową odpowiedzią będzie – „wygoda”. bo przecież konieczność wpisania PINu daje ten sam poziom [ba! wyższy! bo ktoś musi go znać], tylko jest bardziej upierdliwa. zresztą do tokenów też trzeba często podać PIN.

no to czemu nie smart card?

Pozostaje pytanie – czemu jednak nie karty inteligentne, skoro mają tyle zalet? w końcu to, że tokeny są tak ładnie obsługiwane przez przeglądarki i urządzenia to kwestia tego, że powstały standardy, które zostały zaimplementowane przez dostawców. są takie, ale mogły być inne. czego zatem brakuje kartom inteligentnym i czemu nie dostosowano tej technologii do protokołów Chmurowych WebAuthn/CTAP? co przełamało prawo konwergencji, forkując technologię, która wydawała się wygodniejsza [i tańsza] – pozostawiając karty inteligentne w niszy dostępu fizycznego, a stworzono Fast IDentity Online [FIDO]?

podstawowym powodem jest cały model uwierzytelnienia, tzw. authentication workflow. obsługa certyfikatu zorientowana jest na zcentralizowanym modelu. FIDO z założenia jest zdecentralizowane, oparte na szybkiej weryfikacji, bez konieczności dodatkowego sięgania do jakiegoś centralnego serwera. niepotrzebna jest Infrastruktura Klucza Publicznego [PKI] – która ma swoją własną złożoność, problemy, podatności etc…

można z tym wszystkim niby polemizować – że certyfikaty nie muszą być drogie, że wdrożenia PKI to wcale nie musi być nie-wiadomo-jak-skomplikowane… ale jak to wszystko zebrać razem, to po prostu nie tędy droga. tak na prawdę FIDO powinno być ewolucyjnie porównywane z tokenami OTP – np. RSA SecureID – a nie z kartami inteligentnymi. elektronika, która jest w tokenach pozwala na wiele więcej, niż pasywne przechowywanie certyfikatów:

  • generowanie tokenów jednorazowych TOTP/HOTP
  • izolację procesu generacji klucza publicznego bezpośrednio na urządzeniu, dodanie TPM, a więc nie ma praktycznie możliwości przechwycenia części prywatnej. przy klasycznym PKI mamy architekturę serwer-klient, a więc dodatkowy punkt potencjalnej słabości
  • proces uwierzytelniania WebAuthN nie jest trywialny… dodatkowa komplikacja w postaci weryfikacji certyfikatów na serwerach CA zabiła by Internet. kto przepalił godziny na rozwiązywaniu problemów uwierzytelnienia ten wie, że w
  • i w końcu wszystkie te bajery, które nie są bez znaczenia typu możliwość dodania biometrii – np. czytnika odcisków palców [jasne… cena jest kosmiczna, ale są],
  • self-service … [well… można polemizować z tym self-service. nie wszystkie scenariusze pozwalają na self-service…]

w skrócie – wymagana była aktywna elektronika.

pisząc ten art zadałem sobie pytanie – czemu nie połączy się tych dwóch technologii tworząc FIDO2 smart card… i jak to zwykle bywa – ktoś już odpowiedział na to pytanie – a czemu by nie? mam nadzieję kiedyś pracować przy wdrożeniu takiego cuda, jako część Integrated Security System, bo wygląda smacznie.

Exit

jednym z drażniących ograniczeń FIDO jest brak jego natywnej obsługi przez Windows logon. do tego celu można oczywiście wykorzystać system innych firm – jak np. Duo. problemem są koszty rozwiązania – same tokeny FIDO do najtańszych nie należą, a i subskrypcja Duo kosztuje… dochodzi dodatkowy poziom integracji, wybór IdP i tak dalej…

…nie podejmuję się odpowiedzi na pytanie 'dlaczego?’… a w każdym razie nie dzisiaj…

eN.

deduplication by Microsoft

taka ciekawostka a propos eMeSeowego DD…

  • eMeSowy DD działa na poziomie plików – nad sterownikiem NTFS a nie pod nim [..może raczej 'obok’.. albo 'wraz z’… hmmm. ciężko umiejscowić 'filter drivers’ w geometrii przestrzennej (; ].  to zupełnie zmienia logikę działania
  • efekty DD oraz scenariusze zastosowania będą zupełnie inne dla DD macierzowego a tego eMeSowego. dobrym przykładem będzie DD dla backupów SQL – bez względu czy użyje się kompresji czy nie, zysk z DD będzie oscylował w okolicach 7o-8o%. tutaj można poczytać o ciekawych testach z tym związanych. w jednym ze środowisk uzyskałem ratio 92% dla backupów SQL (muszę dodać, że przy małej ilości zmian na bazie, więc test nie jest zbyt miarodajny, ale i tak robi wrażenie).
  • podczas projektowania przestrzeni dyskowej trzeba pamiętać, że operacja nie jest robiona w locie tylko w cyklach -czyli projekt musi zawierać 1oo% przestrzeni dla danych które będą się pojawiać. co więcej – deduplikacji (standardowo) nie podlegają pliki młodsze niż 3 dni,warto ustawić 'minimumFileAge’ na 0 żeby operacja została wykonana od razu jeśli to nie jest wolumen z aktywnie używanymi danymi. jest również wiele typów pliqw, które nie są ruszane, ze względu na to, że z góry wiadomo, że będzie to efektywne – głównie chodzi o już skompresowane pliki. z tego powodu bardzo jestem zdziwiony wynikami z backupem SQL.

eN.

pomniejszanie dysq

w zasadzie od w2k jest możliwość pomniejszania/powiększania dysqw bezpośrednio z disk managera. z niewiadomych powodów, z każdą wersją, powolutq, była dodawana nowa funkcja – w NT5.o tylko extend, w NT6.o extend i shrink ale max do 5o% powierzchni izdaje się, że nie można było ruszyć boot partition i system partition, w NT6.1 znów zniesiono obostrzenia aż do NT6.3 gdzie teoretycznie można sobie zmniejszać i zwiększać bez problemu…

to tyle, jeśli chodzi o teorię – czas na trochę praktyki, bo [jak to usłyszałem ostatnio qilqrotnie w ciągu krótkiego czasu] życie weryfiqje. obostrzenia oczywiście są. pierwszym z nich są 'nieprzenaszalne pliki’ – czyli takie, do których system trzyma konkretny adres i z pewnych względów nie może ich ruszyć. do takich należą np. restore points, pagefile, klucze BitLocer i kilka innych specyficznych obiektów. przy próbie zmniejszenia dysq, system automatycznie wylicza przestrzeń do pierwszego takiego pliq, wskazując maksymalną wielkość, o którą można dysk zmniejszyć.

scenariusz na jaki trafiłem, i skąd bierze się ten wpis jest taki, że po miesiącu pracy dostałem nowego kompa. przeniesienie się jest zawsze mało przyjemne, bo pomimo, że prawie wszystko jest w chmurze, zawsze zostaje sporo poinstalowanych i skonfigurowanych już aplikacji. BUUUEEEH. ponowna instalacja śmierdzi. prosty wniosek – zrobię z tego VHDX, skopiuję na nowego kompa i będę sobie bootwał z niego. proste. tyle, że okazało się, że w jednym kompie jest 5ooGB a w nowym 12oGB dysq. system nie pozwala zmniejszyć dysq o tak dużą wartość. co zrobić?

w pierwszej kolejności trzeba sprawdzić co nas bloqje. w suqrs przyjdzie zajrzenie do eventloga Application i przefiltrowanie po zdarzeniach z ID 259. zdarzenie to jest generowane przez … defrag [sic!], w momencie, kiedy włączamy wizarda w diskmanagerze:

EventID 259
 A volume shrink analysis was initiated on volume (C:). 
This event log entry details information about the last unmovable file that could 
limit the maximum number of reclaimable bytes.
Diagnostic details:
 - The last unmovable file appears to be: \System Volume Information\FVE2.{e40ad34d-
dae9-4bc7-95bd-b16218c10f72}.3::$DATA
 - The last cluster of the file is: 0x4d93bba
 - Shrink potential target (LCN address): 0xac8878
 - The NTFS file flags are: ---AD
 - Shrink phase: <analysis>

FVE2 to właśnie klucz BL. swoją drogą przy bootowaniu systemu z VHDX trzeba pamiętać, że BL nie jest obsługiwany. nie jest również obsługiwana hibernacja. to tak zanim się podejmie decyzję, czy na pewno ta droga jest prawidłowa. wyłączyłem BL, wyłączyłem Restore Points, i wyłączyłem… czy też chciałem wyłączyć Pagefile. już nie pierwszy raz zdarzyło mi się, że pomimo wyłączenie PF i restartu, ten wracał jak boomerang. dopiero konfiguracja z linii poleceń faktycznie się go pozbyła

wmic pagefileset delete

jeszcze ręczne wyczyszczenie katalogu System Volume Information i voila! po uruchomieniu wizarda zmniejszania dysq mogę go sqrczyć do maleńkości… szkoda tylko, że kiedy próbuję – dostaję komunikat, że system nie może zmniejszyć partycji ponieważ… wybrałem za dużą wartość /: tutaj rozwiązaniem okazało się krokowe zmniejszanie – najpierw 2ooGB a potem po 5oGB… i jakoś system to przełknął. ciężko powiedzieć zatem po co ten komunikat i o co cho.

teraz disk2vhd i prawie już. prawie, ponieważ disk2vhd nie ma opcji wyboru, jaki typ dysq chcemy uzyskać – jest na sztywno dynamic. no i trzeba mu zmniejszyć wielkość – bo o ile partycja jest sqrczona, to sam dysk pozostaje wielki. i tu kolejne zaskoczenie. kiedyś były toole, które na plikach vhd łatwo i przyjemnie robiły takie operacje. od czasu, kiedy wszystkie narzędzia są dostępne w systemie, i pojawił się format vhdx, narzędzi brak. systemowe narzędzia natomiast mają podstawową wadę – PowerShellowe commandlety Convert-VHD czy Resize-VHD wymagają, aby w systemie działała usługa Hyper-v. niby nic… a jednak cyc. nie udało mi się znaleźć żadnego darmowego toola, który by wykonywał operacje na dyskach vhdx.

ponieważ ta instancja systemu i tak była do wyrzucenia, a poszukiwania były raczej z takiej ciekawości i niedowiary, zainstalowałem Hv, skonwertowałem dysk, potem kopia na nowy, bcdboot i w końcu sukces. ale i tak, pomimo, że finalnie zabrało mi to tyle samo czasu co instalacja system+aplikacje, było to zajęcie dużo przyjemniejsze q:

eN.

replikacyjna magia

są takie, jak to ktoś kiedyś pięknie przetłumaczył, dziwnostki. jak się na taką trafi to jak los w antylotto. właśnie straciłem 3h na debugowaniu takiego wynalazq z programu „niedowiary”. napisałem sobie skrypt, który sprawdza wszystkie hosty na SCVMM a potem odpytuje je o status replikacji i wysyła go mailem. działa ślicznie – jak odpala się z konsoli.

…wrzucam jako zadanie task scheduler… skrypt niby się odpala, ale wyraźnie coś nie do końca, bo output jest niepełny. zajmuje mi chwilę, żeby zawęzić niedziałanie do komendy get-vmreplication – najwyraźniej się wywala /: testowałem wszystko – sprawdzałem kontekst wywołania, poprawność skryptu, nawet szukałem pod względem tego, czy może get-vmreplication z jakiś powodu nie działa jako zadanie kalendarza. w końcu postanowiłem przejść do podstaw – wycinając cały skrypt i zostawiając tylko to jedno polecenie, w różnym kodowaniu – ANSI/UTF8. dupa. nadal zmienna jest pusta

$ReplicatedVMs = Get-VMReplication -computername hostname
 get-variable ReplicatedVMs|out-file C:\ReplicationReporting\test.out

w końcu założyłem nowy task i… działa! no więc odtwarzam pełną definicję zadania… znów nie działa @_@ o co qrva c’mon?!

teraz już szybkie testy i oto przed państwem dziwny, przedziwny, niewytłumaczalny wynik:

jeśli w trigerze taska ustawiona jest opcja „Stop task if it runs longer then” – get-vmreplication nic nie zwraca

sprawdzałem dla różnych wartości, i nie ważne, że sam task jest odpalany ręcznie /: cuda na kiju. nie testowałem na innych serverach – u mnie to jest w2k12 standard z SCVMM.

First world problem

Ot przykład z życia dlaczego Microsoft na rynku aplikacji mobilnych sporo ma jeszcze do nadrobienia:

Screenshot_2014-03-13-20-58-30

Jak już zaznaczy się link, skopiuje, otworzy przeglądarkę i go wklei to, jakżeby inaczej, do mobilnej wersji strony nie odsyła:)

Osobliwości IT – trudne sprawy

Autentyk z działu help-desk. Fakt że firma z branży rolniczej, a kontakt był jedną z placówek zlokalizowanych hen,  gdzieś w Polsce….

​Po 20 minutach uruchamiania TeamViewera  doszło w jednym oddziale naszego Klienta do podania hasła.
Słyszę:
-” K**** j**** mać co to za dziwna litera?​ Takie trochę „p” tylko z laską przestawioną na drugą stronę… „