Owsianka DIY

W zeszłym roku pisałem o owsiance proteinowej i zwykłej, a także o tym, że mi pasują i myślę o wersji DIY. Od czasu pandemii owsianki wróciły do łask, a nawet stały się regularnym elementem poranków. No i w końcu, głównie z racji redukcji ilości śmieci, ale też wygody, przeszedłem na wersję DIY. Niewiele ma ona wspólnego z oryginałem, ale… mi pasuje.

Owsianka DIY jest prosta, robiona na oko i podatna na modyfikacje, więc dane orientacyjnie. Przepis w sumie trochę w ramach inspiracji, trochę dla pamięci, a trochę będzie to eksperyment z polecaniem produktów na Allegro[1].

Baza owsianki:

  1. Musli. Tak naprawdę dowolne. Najtańsze z Biedronki się sprawdza. Chodzi o to, żeby były jakieś urozmaicenia, typu rodzynki, inne płatki itp., a nie tylko płatki owsiane. Około 33% objętości bazy.
  2. Płatki owsiane górskie. Np. takie, choć kupuję w sklepie stacjonarnym. Około 66% objętości bazy.
  3. Owoce liofilizowane. Mi najbardziej pasuje czarna porzeczka, bliżej oryginału byłaby malina, można też spróbować truskawki.

Teraz przygotowanie pojedynczego kubka/porcji:

  1. Około 12 łyżeczek bazy.
  2. 1-2 łyżeczki kaszki Bobovita. Najlepiej bezmlecznej, na przykład takiej, chociaż smak i rodzaj są raczej drugorzędne. Chodzi o zmianę konsystencji i wchłonięcie ew. nadmiaru wody, zwłaszcza przy wersji bez dodatku białka. Dodatkowo dobrze wpływa na rozdrobnienie białka.
  3. 20 g (1 miarka) białka WPC. O ile ma być wersja proteinowa. Ja zwykle dodaję, i wtedy jedna łyżeczka kaszki, zamiast dwóch.
  4. Można dodać ziarno słonecznika. Odkąd używam musli, raczej pomijam.

Zamieszać dokładnie suche składniki owsianki, zalać gorącą wodą nieco ponad poziom suchej masy, zamieszać dokładnie już z wodą, poczekać aż się wchłonie (można dodatkowo zamieszać w trakcie).

[1] W ramach dostępnego od niedawna programu Allegro Polecam. Jeśli kupisz coś wchodząc z linków we wpisie, to być może wpadnie mi parę groszy na owsiankę. Pewnie za jakiś czas, jeśli nie zapomnę, dam znać jak to wypadło, choć nie mam złudzeń.

Dlaczego k-anonimowość nie jest dobra przy hasłach?

Na z3s.pl pojawił się artykuł o tym, czym jest k-anonimowość. Jest to dobry artykuł i warto go przeczytać przed lekturą tego wpisu. Nie zgadzam się jedynie z tezą, że w przypadku haseł jest to bezpieczna metoda sprawdzania. Napisałem komentarz, ale pewnie nie wszyscy czytelnicy bloga tam trafią. Ponieważ bawię się z bazą hashy z HIBP i planuję wkrótce wpis na ten temat, uznałem, że jest dobra okazja do wstępu.

Moja teza jest taka, że w przypadku haseł k-anonimowość wcale nie jest taka bezpieczna, jak jest to przedstawiane. Zgodnie z artykułem obecnie dla hashy z bazy HIBP pierwsze 5 znaków występuje od 381 do 584. Czyli podczas sprawdzenia strona trzecia nie poznaje ani hasła, ani jego pełnego hasha. Przekazywane jest jedynie pierwszych 5 znaków hasha, czyli – tu moja interpretacja – ma jedynie 1/381 do 1/584 prawdopodobieństwo, że zna właściwy hash.

Gdyby przyjąć, że strona trzecia jest złośliwa, warto też przyjąć, że jest inteligentna. Czyli zamiast prawdopodobieństwa zwykłego użyje prawdopodobieństwa ważonego, uwzględniając ilość wystąpień danego hasha. Dla przykładu z artykułu na z3s.pl i hasła P@ssw0rd mamy zwracanych 543 różnych hashy:

curl -s https://api.pwnedpasswords.com/range/21BD1 | wc -l

Natomiast suma wystąpień wszystkich hashy w momencie pisania tego wpisu wynosi 60808.

curl -s https://api.pwnedpasswords.com/range/21BD1 | awk -F ":" '{sum += $2} END {print sum}'

Nasz hash wystąpił 52579 razy. Znając zwyczaje ludzi dotyczące haseł i stosując prawdopodobieństwo ważone uzyskujemy 86% szansę na to, że chodzi o hash należący do hasła P@ssw0rd. Pewności nie ma, ale z 1/543 czyli z ~0,18% robi się 86%, czyli jakieś 467 razy więcej. Ups!

Oczywiście nie znamy tu samego hasła. Znamy jedynie – a i to jedynie ze sporym prawdopodobieństwem – jego hash. O tym, że to niekoniecznie jest problem, może będzie w którymś kolejnym wpisie.

W każdym razie gdybym był serwisem, to bałbym się odpytywać serwis trzeci o hashe haseł moich użytkowników. Użytkowników podejrzewam o proste, słownikowe hasła, jakiś serwis trzeci. Zwłaszcza jeśli ten serwis ma/może mieć także inne informacje, które pozwalają mu ustalić kto pyta o hasło. Tak właśnie może być w przypadku Cloudflare, który może dostawać część ruchu od użytkownika w ramach CDN, DNS lub DoH. Prosta korelacja czasowa może w tym przypadku prowadzić do powiązania hasha hasła z IP użytkownika. Jeśli chcemy sprawdzać hasła, to lepszym rozwiązaniem jest stworzenie lokalnej kopii bazy którą pobierzemy z HIBP.

Co nie znaczy oczywiście, że k-anonimowość ogólnie nie spełnia swojego zadania. Po prostu mam wrażenie, że akurat w przypadku hashy hasła i tej konkretnej implementacji nie jest tak bezpieczna, jak jest to przedstawiane.

Warto też zauważyć, że hasło z którym mamy tu do czynienia jest proste/populare. Dla innych pięcioznakowych początków hashy wystąpienia mogą rozkładać się inaczej, bez tak silnego wskazania na konkretny hash.

UPDATE Tak naprawdę nie ma potrzeby używania całej bazy hashy i ilości ich wystąpień z HIBP (>20GB). Najczęściej występujące 100 tys. hashy to raptem 3,2 MB. Najczęstszy milion – 32 MB.

Aktualizacje macOS

Pierwszą aktualizacją macOS, którą robiłem, była ta między „dużymi” wersjami, do wersji Catalina. Wtedy byłem umiarkowanie zadowolony, bo to duża aktualizacja. I pierwsza. I się udała. Od tego czasu miałem parę razy okazję aktualizować system między „małymi” wersjami i… wyrobiłem sobie zdanie.

Źródło: http://www.highstreetcomputers.com/apple-logo-broken/

Aktualizacje systemu w macOS to porażka, generalnie. „Duże” może nie są najgorsze, ale „małe” są tragiczne. Spójrzmy na listę aktualizacji Cataliny na Wikipedii, linkującą do opisu aktualizacji na stronach Apple. Od końca października 2019 do lipca 2020 było sześć aktualizacji. Każda to przynajmniej 3 GB do pobrania i blisko godzina stracona na aktualizację.

No właśnie, jeśli ktoś zastanawia się, o co mi w ogóle chodzi i czy da się system aktualizować lepiej, to szybko nakreślę jak wygląda proces aktualizacji w Linuksie. Otóż sprowadza się do pobrania pakietów i wykonania restartu. Cały czas można pracować na komputerze. Restart i okoliczne czynności nie trwają pół godziny, to zwykły reboot, jak każdy inny, czyli pewnie minuta. Aktualizowany jest zarówno kernel, kluczowe pakiety, jak i pakiety opcjonalne. Nie trzeba pobierać 3 GB, ale to już detal. Chodzi głównie o brak przerwy w możliwości korzystania z komputera.

No właśnie, gdy pisałem o aktualizacji do Cataliny i porównywałem jej czas z aktualizacją Debiana, popełniłem błąd. Porównywałem jabłka z gruszkami – w przypadku macOS brałem pod uwagę czas aktualizacji samego systemu, czyli podstawki, a w przypadku Linuksa systemu i wszystkich dodatkowych aplikacji będących w repozytoriach, a trochę tego jest (LibreOffice, Firefox, Chromium). Nie jest to aż tak ważne, bo to, czy pobieranie trwa pół godziny, czy godzinę nie ma większego znaczenia, jeśli można korzystać z systemu. Kluczowy jest czas niedostępności komputera.

Tyle o aktualizacjach systemu w makach, dopóki coś się diametralnie nie zmieni albo nie wybuchnie przy upgrade, nie będę wracał do tego smutnego tematu.