From 6b30fb93feb367657fd1e77289de818b518cd027 Mon Sep 17 00:00:00 2001
From: Tommy <contact@tommytran.io>
Date: Sun, 17 Jul 2022 06:00:20 -0400
Subject: [PATCH] New Hugo build

Signed-off-by: Tommy <contact@tommytran.io>
---
 public/about/index.html                               |  2 +-
 public/apps/f-droid-security-analysis/index.html      |  2 +-
 public/donate/index.html                              |  2 +-
 public/index.xml                                      | 11 +++++++++++
 public/knowledge/index.html                           |  2 +-
 .../knowledge/multi-factor-authentication/index.html  |  2 +-
 .../index.html                                        | 11 +++++++++++
 public/os/docker-and-oci-hardening/index.html         |  5 +++--
 public/os/index.html                                  |  6 ++++--
 public/os/index.xml                                   | 11 +++++++++++
 public/os/linux-insecurities/index.html               |  2 +-
 public/os/securing-openssh-with-fido2/index.html      |  2 +-
 public/sitemap.xml                                    |  2 ++
 public/tags/index.html                                |  2 +-
 public/tags/knowledge-base/index.html                 |  2 +-
 public/tags/linux/index.html                          |  6 ++++--
 public/tags/linux/index.xml                           | 11 +++++++++++
 public/tags/operating-system/index.html               |  6 ++++--
 public/tags/operating-system/index.xml                | 11 +++++++++++
 public/tags/security/index.html                       |  9 +++++----
 public/tags/security/index.xml                        | 11 +++++++++++
 public/tags/security/page/2/index.html                |  6 ++++++
 22 files changed, 103 insertions(+), 21 deletions(-)
 create mode 100644 public/os/choosing-your-desktop-linux-distribution/index.html
 create mode 100644 public/tags/security/page/2/index.html

diff --git a/public/about/index.html b/public/about/index.html
index f36ca19..3a73005 100644
--- a/public/about/index.html
+++ b/public/about/index.html
@@ -8,7 +8,7 @@ Tommy System Administrator. Benevolent dictator for life @privsec.dev.
 Website: tommytran.io"><meta property="og:type" content="article"><meta property="og:url" content="https://privsec.dev/about/"><meta property="article:section" content><meta name=twitter:card content="summary"><meta name=twitter:title content="About Us"><meta name=twitter:description content="PrivSec.dev is made by a group of enthusiastic individuals looking to provide practical privacy and security advice for the end user. We are security researchers, developers, system administrators&mldr; generally people with technical knowledge and work in the field.
 We focus on in-depth system configuration, security analysis, and software/hardware recommendations. Our site is based on technical merits, not ideologies and politics.
 Tommy System Administrator. Benevolent dictator for life @privsec.dev.
-Website: tommytran.io"><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"About Us","item":"https://privsec.dev/about/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"About Us","name":"About Us","description":"PrivSec.dev is made by a group of enthusiastic individuals looking to provide practical privacy and security advice for the end user. We are security researchers, developers, system administrators\u0026hellip; generally people with technical knowledge and work in the field.\nWe focus on in-depth system configuration, security analysis, and software/hardware recommendations. Our site is based on technical merits, not ideologies and politics.\nTommy System Administrator. Benevolent dictator for life @privsec.dev.\nWebsite: tommytran.io","keywords":[],"articleBody":"PrivSec.dev is made by a group of enthusiastic individuals looking to provide practical privacy and security advice for the end user. We are security researchers, developers, system administrators… generally people with technical knowledge and work in the field.\nWe focus on in-depth system configuration, security analysis, and software/hardware recommendations. Our site is based on technical merits, not ideologies and politics.\nTommy System Administrator. Benevolent dictator for life @privsec.dev.\nWebsite: tommytran.io\nMatrix: @tommy:arcticfoxes.net\nEmail: tommy@privsec.dev\nJune Security Researcher. GrapheneOS Developer. Excessively obsessed with Homestuck.\nMatrix: @june:grapheneos.org\nEmail: june@privsec.dev\nWonderfall Random guy passing by on the Internet who is interested in all kinds of things. Total nerd.\nWebsites: wonderfall.space and wonderfall.dev\nMatrix: @wonderfall:lysergide.dev\nLberrymage Accrescent developer. Rust shill and man who can’t stop recycling names of his previous projects.\nWebsite: accrescent.app\nMatrix: @lberrymage:matrix.org\nRandomhydrosol GrapheneOS Developer. Friendliest Indian tech support on planet Earth.\nMatrix: @randomhydrosol:grapheneos.org\nMadaidan Security Researcher. Whonix developer. Uses Firefox, Telegram, and Linux against his own advice like a hypocrite.\nWebsite: https://madaidans-insecurities.github.io/\nMatrix: @madaidan.:matrix.org\n","wordCount":"164","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"PrivSec Team"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/about/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a></div><h1 class=post-title>About Us</h1><div class=post-meta>1 min&nbsp;·&nbsp;164 words&nbsp;·&nbsp;PrivSec Team&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/content/about.md rel="noopener noreferrer" target=_blank>Suggest Changes</a></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#tommy aria-label=Tommy>Tommy</a></li><li><a href=#june aria-label=June>June</a></li><li><a href=#wonderfall aria-label=Wonderfall>Wonderfall</a></li><li><a href=#lberrymage aria-label=Lberrymage>Lberrymage</a></li><li><a href=#randomhydrosol aria-label=Randomhydrosol>Randomhydrosol</a></li><li><a href=#madaidan aria-label=Madaidan>Madaidan</a></li></ul></div></details></div><div class=post-content><p>PrivSec.dev is made by a group of enthusiastic individuals looking to provide practical privacy and security advice for the end user. We are security researchers, developers, system administrators&mldr; generally people with technical knowledge and work in the field.</p><p>We focus on in-depth system configuration, security analysis, and software/hardware recommendations. Our site is based on technical merits, not ideologies and politics.</p><hr><h3 id=tommy>Tommy<a hidden class=anchor aria-hidden=true href=#tommy>#</a></h3><p>System Administrator. Benevolent dictator for life @privsec.dev.</p><p><strong>Website</strong>: <a href=https://tommytran.io>tommytran.io</a><br><strong>Matrix</strong>: <a href=https://matrix.to/#/@tommy:arcticfoxes.net>@tommy:arcticfoxes.net</a><br><strong>Email</strong>: <a href=mailto:tommy@privsec.dev>tommy@privsec.dev</a></p><h3 id=june>June<a hidden class=anchor aria-hidden=true href=#june>#</a></h3><p>Security Researcher. GrapheneOS Developer. Excessively obsessed with Homestuck.</p><p><strong>Matrix</strong>: <a href=https://matrix.to/#/@june:grapheneos.org>@june:grapheneos.org</a><br><strong>Email</strong>: <a href=mailto:june@privsec.dev>june@privsec.dev</a></p><h3 id=wonderfall>Wonderfall<a hidden class=anchor aria-hidden=true href=#wonderfall>#</a></h3><p>Random guy passing by on the Internet who is interested in all kinds of things. Total nerd.</p><p><strong>Websites</strong>: <a href=https://wonderfall.space>wonderfall.space</a> and <a href=https://wonderfall.dev>wonderfall.dev</a><br><strong>Matrix</strong>: <a href=https://matrix.to/#/@wonderfall:lysergide.dev>@wonderfall:lysergide.dev</a></p><h3 id=lberrymage>Lberrymage<a hidden class=anchor aria-hidden=true href=#lberrymage>#</a></h3><p>Accrescent developer. Rust shill and man who can&rsquo;t stop recycling names of his previous projects.</p><p><strong>Website</strong>: <a href=https://accrescent.app/>accrescent.app</a><br><strong>Matrix</strong>: <a href=https://matrix.to/#/@lberrymage:matrix.org>@lberrymage:matrix.org</a></p><h3 id=randomhydrosol>Randomhydrosol<a hidden class=anchor aria-hidden=true href=#randomhydrosol>#</a></h3><p>GrapheneOS Developer. Friendliest Indian tech support on planet Earth.</p><p><strong>Matrix</strong>: <a href=https://matrix.to/#/@randomhydrosol:grapheneos.org>@randomhydrosol:grapheneos.org</a></p><h3 id=madaidan>Madaidan<a hidden class=anchor aria-hidden=true href=#madaidan>#</a></h3><p>Security Researcher. Whonix developer. Uses Firefox, Telegram, and Linux against his own advice like a hypocrite.</p><p><strong>Website</strong>: <a href=https://madaidans-insecurities.github.io/>https://madaidans-insecurities.github.io/</a><br><strong>Matrix</strong>: <a href=https://matrix.to/#/@madaidan.:matrix.org>@madaidan.:matrix.org</a></p></div><footer class=post-footer><ul class=post-tags></ul></footer></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+Website: tommytran.io"><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"About Us","item":"https://privsec.dev/about/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"About Us","name":"About Us","description":"PrivSec.dev is made by a group of enthusiastic individuals looking to provide practical privacy and security advice for the end user. We are security researchers, developers, system administrators\u0026hellip; generally people with technical knowledge and work in the field.\nWe focus on in-depth system configuration, security analysis, and software/hardware recommendations. Our site is based on technical merits, not ideologies and politics.\nTommy System Administrator. Benevolent dictator for life @privsec.dev.\nWebsite: tommytran.io","keywords":[],"articleBody":"PrivSec.dev is made by a group of enthusiastic individuals looking to provide practical privacy and security advice for the end user. We are security researchers, developers, system administrators… generally people with technical knowledge and work in the field.\nWe focus on in-depth system configuration, security analysis, and software/hardware recommendations. Our site is based on technical merits, not ideologies and politics.\nTommy System Administrator. Benevolent dictator for life @privsec.dev.\nWebsite: tommytran.io\nMatrix: @tommy:arcticfoxes.net\nEmail: tommy@privsec.dev\nJune Security Researcher. GrapheneOS Developer. Excessively obsessed with Homestuck.\nMatrix: @june:grapheneos.org\nEmail: june@privsec.dev\nWonderfall Random guy passing by on the Internet who is interested in all kinds of things. Total nerd.\nWebsites: wonderfall.space and wonderfall.dev\nMatrix: @wonderfall:lysergide.dev\nLberrymage Accrescent developer. Rust shill and man who can’t stop recycling names of his previous projects.\nWebsite: accrescent.app\nMatrix: @lberrymage:matrix.org\nRandomhydrosol GrapheneOS Developer. Friendliest Indian tech support on planet Earth.\nMatrix: @randomhydrosol:grapheneos.org\nMadaidan Security Researcher. Whonix developer. Uses Firefox, Telegram, and Linux against his own advice like a hypocrite.\nWebsite: https://madaidans-insecurities.github.io/\nMatrix: @madaidan.:matrix.org\n","wordCount":"164","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"PrivSec Team"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/about/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a></div><h1 class=post-title>About Us</h1><div class=post-meta>1 min&nbsp;·&nbsp;164 words&nbsp;·&nbsp;PrivSec Team&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/blob/main/content/about.md rel="noopener noreferrer" target=_blank>Suggest Changes</a></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#tommy aria-label=Tommy>Tommy</a></li><li><a href=#june aria-label=June>June</a></li><li><a href=#wonderfall aria-label=Wonderfall>Wonderfall</a></li><li><a href=#lberrymage aria-label=Lberrymage>Lberrymage</a></li><li><a href=#randomhydrosol aria-label=Randomhydrosol>Randomhydrosol</a></li><li><a href=#madaidan aria-label=Madaidan>Madaidan</a></li></ul></div></details></div><div class=post-content><p>PrivSec.dev is made by a group of enthusiastic individuals looking to provide practical privacy and security advice for the end user. We are security researchers, developers, system administrators&mldr; generally people with technical knowledge and work in the field.</p><p>We focus on in-depth system configuration, security analysis, and software/hardware recommendations. Our site is based on technical merits, not ideologies and politics.</p><hr><h3 id=tommy>Tommy<a hidden class=anchor aria-hidden=true href=#tommy>#</a></h3><p>System Administrator. Benevolent dictator for life @privsec.dev.</p><p><strong>Website</strong>: <a href=https://tommytran.io>tommytran.io</a><br><strong>Matrix</strong>: <a href=https://matrix.to/#/@tommy:arcticfoxes.net>@tommy:arcticfoxes.net</a><br><strong>Email</strong>: <a href=mailto:tommy@privsec.dev>tommy@privsec.dev</a></p><h3 id=june>June<a hidden class=anchor aria-hidden=true href=#june>#</a></h3><p>Security Researcher. GrapheneOS Developer. Excessively obsessed with Homestuck.</p><p><strong>Matrix</strong>: <a href=https://matrix.to/#/@june:grapheneos.org>@june:grapheneos.org</a><br><strong>Email</strong>: <a href=mailto:june@privsec.dev>june@privsec.dev</a></p><h3 id=wonderfall>Wonderfall<a hidden class=anchor aria-hidden=true href=#wonderfall>#</a></h3><p>Random guy passing by on the Internet who is interested in all kinds of things. Total nerd.</p><p><strong>Websites</strong>: <a href=https://wonderfall.space>wonderfall.space</a> and <a href=https://wonderfall.dev>wonderfall.dev</a><br><strong>Matrix</strong>: <a href=https://matrix.to/#/@wonderfall:lysergide.dev>@wonderfall:lysergide.dev</a></p><h3 id=lberrymage>Lberrymage<a hidden class=anchor aria-hidden=true href=#lberrymage>#</a></h3><p>Accrescent developer. Rust shill and man who can&rsquo;t stop recycling names of his previous projects.</p><p><strong>Website</strong>: <a href=https://accrescent.app/>accrescent.app</a><br><strong>Matrix</strong>: <a href=https://matrix.to/#/@lberrymage:matrix.org>@lberrymage:matrix.org</a></p><h3 id=randomhydrosol>Randomhydrosol<a hidden class=anchor aria-hidden=true href=#randomhydrosol>#</a></h3><p>GrapheneOS Developer. Friendliest Indian tech support on planet Earth.</p><p><strong>Matrix</strong>: <a href=https://matrix.to/#/@randomhydrosol:grapheneos.org>@randomhydrosol:grapheneos.org</a></p><h3 id=madaidan>Madaidan<a hidden class=anchor aria-hidden=true href=#madaidan>#</a></h3><p>Security Researcher. Whonix developer. Uses Firefox, Telegram, and Linux against his own advice like a hypocrite.</p><p><strong>Website</strong>: <a href=https://madaidans-insecurities.github.io/>https://madaidans-insecurities.github.io/</a><br><strong>Matrix</strong>: <a href=https://matrix.to/#/@madaidan.:matrix.org>@madaidan.:matrix.org</a></p></div><footer class=post-footer><ul class=post-tags></ul></footer></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
         <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script><script>document.querySelectorAll("pre > code").forEach(e=>{const n=e.parentNode.parentNode,t=document.createElement("button");t.classList.add("copy-code"),t.innerHTML="copy";function s(){t.innerHTML="copied!",setTimeout(()=>{t.innerHTML="copy"},2e3)}t.addEventListener("click",t=>{if("clipboard"in navigator){navigator.clipboard.writeText(e.textContent),s();return}const n=document.createRange();n.selectNodeContents(e);const o=window.getSelection();o.removeAllRanges(),o.addRange(n);try{document.execCommand("copy"),s()}catch{}o.removeRange(n)}),n.classList.contains("highlight")?n.appendChild(t):n.parentNode.firstChild==n||(e.parentNode.parentNode.parentNode.parentNode.parentNode.nodeName=="TABLE"?e.parentNode.parentNode.parentNode.parentNode.parentNode.appendChild(t):e.parentNode.appendChild(t))})</script></body></html>
\ No newline at end of file
diff --git a/public/apps/f-droid-security-analysis/index.html b/public/apps/f-droid-security-analysis/index.html
index 86693fb..0c556f2 100644
--- a/public/apps/f-droid-security-analysis/index.html
+++ b/public/apps/f-droid-security-analysis/index.html
@@ -5,7 +5,7 @@ The main goal of this write-up was to inform users so they can make responsible
 Before we start, a few things to keep in mind:
 The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else&rsquo;s work."><meta property="og:type" content="article"><meta property="og:url" content="https://privsec.dev/apps/f-droid-security-analysis/"><meta property="article:section" content="apps"><meta name=twitter:card content="summary"><meta name=twitter:title content="F-Droid Security Analysis"><meta name=twitter:description content="F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider.
 Before we start, a few things to keep in mind:
-The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else&rsquo;s work."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Applications","item":"https://privsec.dev/apps/"},{"@type":"ListItem","position":3,"name":"F-Droid Security Analysis","item":"https://privsec.dev/apps/f-droid-security-analysis/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"F-Droid Security Analysis","name":"F-Droid Security Analysis","description":"F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider.\nBefore we start, a few things to keep in mind:\nThe main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else\u0026rsquo;s work.","keywords":["software","android","security"],"articleBody":"F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider.\nBefore we start, a few things to keep in mind:\nThe main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else’s work. I have respect for any work done in the name of good intentions. Likewise, please don’t misinterpret the intentions of this article. You have your own reasons for using open-source or free/libre/whatever software which won’t be discussed here. A development model shouldn’t be an excuse for bad practices and shouldn’t lure you into believing that it can provide strong guarantees it cannot. A lot of information in this article is sourced from official and trusted sources, but you’re welcome to do your own research. These analyses do not account for threat models and personal preferences. As the author of this article, I’m only interested in facts and not ideologies. This is not an in-depth security review, nor is it exhaustive.\n1. The trusted party problem To understand why this is a problem, you’ll have to understand a bit about F-Droid’s architecture, the things it does very differently from other app repositories, and the Android platform security model (some of the issues listed in this article are somewhat out of the scope of the OS security model, but the majority is).\nUnlike other repositories, F-Droid signs all the apps in the main repository with its own signing keys (unique per app) at the exception of the very few reproducible builds. A signature is a mathematical scheme that guarantees the authenticity of the applications you download. Upon the installation of an app, Android pins the signature across the entire OS (including user profiles): that’s what we call a trust-on-first-use model since all subsequent updates of the app must have the corresponding signature to be installed.\nNormally, the developer is supposed to sign their own app prior to its upload on a distribution channel, whether that is a website or a traditional repository (or both). You don’t have to trust the source (usually recommended by the developer) except for the first installation: future updates will have their authenticity cryptographically guaranteed. The issue with F-Droid is that all apps are signed by the same party (F-Droid) which is also not the developer. You’re now adding another party you’ll have to trust since you still have to trust the developer anyway, which isn’t ideal: the fewer parties, the better.\nOn the other hand, Play Store now manages the app signing keys too, as Play App Signing is required for app bundles which are required for new apps since August 2021. These signing keys can be uploaded or automatically generated, and are securely stored by Google Cloud Key Management Service. It should be noted that the developer still has to sign the app with an upload key so that Google can verify its authenticity before signing it with the app signing key. For apps created before August 2021 that may have not opted in Play App Signing yet, the developer still manages the private key and is responsible for its security, as a compromised private key can allow a third party to sign and distribute malicious code.\nF-Droid requires that the source code of the app is exempt from any proprietary library or ad service, according to their inclusion policy. Usually, that means that some developers will have to maintain a slightly different version of their codebase that should comply with F-Droid’s requirements. Besides, their “quality control” offers close to no guarantees as having access to the source code doesn’t mean it can be easily proofread. Saying Play Store is filled with malicious apps is beyond the point: the false sense of security is a real issue. Users should not think of the F-Droid main repository as free of malicious apps, yet unfortunately many are inclined to believe this.\nBut… can’t I just trust F-Droid and be done with it?\nYou don’t have to take my word for it: they openly admit themselves it’s a very basic process relying on badness enumeration (this doesn’t work by the way) which consists in a few scripts scanning the code for proprietary blobs and known trackers. You are therefore not exempted from trusting upstream developers and it goes for any repository.\nA tempting idea would be to compare F-Droid to the desktop Linux model where users trust their distribution maintainers out-of-the-box (this can be sane if you’re already trusting the OS anyway), but the desktop platform is intrinsically chaotic and heterogeneous for better and for worse. It really shouldn’t be compared to the Android platform in any way.\nWhile we’ve seen that F-Droid controls the signing servers (much like Play App Signing), F-Droid also fully controls the build servers that run the disposable VMs used for building apps. And as of July 2022, their guest VM image officially runs a version of Debian which reached EOL. Undoubtedly, this raises questions about their whole infrastructure security.\nHow can you be sure that the app repository can be held to account for the code it delivers?\nF-Droid’s answer, interesting yet largely unused, is build reproducibility. While deterministic builds are a neat idea in theory, it requires the developer to make their toolchain match with what F-Droid provides. It’s additional work on both ends sometimes resulting in apps severely lagging behind in updates, so reproducible builds are not as common as we would have wanted. It should be noted that reproducible builds in the main repository can be exclusively developer-signed.\nGoogle’s approach is code transparency for app bundles, which is a simple idea addressing some of the concerns with Play App Signing. A JSON Web Token (JWT) signed by a key private to the developer is included in the app bundle before its upload to Play Store. This token contains a list of DEX files and native .so libraries and their hashes, allowing end-users to verify that the running code was built and signed by the app developer. Code transparency has known limitations, however: not all resources can be verified, and this verification can only be done manually since it’s not part of the Android platform itself (so requiring a code transparency file cannot be enforced by the OS right now). Despite its incompleteness, code transparency is still helpful, easy to implement, and thus something we should see more often as time goes by.\nWhat about other app repositories such as Amazon?\nTo my current knowledge, the Amazon Appstore has always been wrapping APKs with their own code (including their own trackers), and this means they were effectively resigning submitted APKs.\nIf you understood correctly the information above, Google can’t do this for apps that haven’t opted in Play App Signing. As for apps concerned by Play App Signing, while Google could technically introduce their own code like Amazon, they wouldn’t do that without telling about it since this will be easily noticeable by the developer and more globally researchers. They have other means on the Android app development platform to do so. Believing they won’t do that based on this principle is not a strong guarantee, however: hence the above paragraph about code transparency for app bundles.\nHuawei AppGallery seems to have a similar approach to Google, where submitted apps could be developer-signed, but newer apps will be resigned by Huawei.\n2. Slow and irregular updates Since you’re adding one more party to the mix, that party is now responsible for delivering proper builds of the app: it’s a common thing among traditional Linux distributions and their packaging system. They have to catch up with upstream on a regular basis, but very few do it well (Arch Linux comes to my mind). Others, like Debian, prefer making extensive downstream changes and delivering security fixes for a subset of vulnerabilities assigned to a CVE (yeah, it’s as bad as it sounds, but that’s another topic).\nNot only does F-Droid require specific changes for the app to comply with its inclusion policy, which often leads to more maintenance work, it also has a rather strange way of triggering new builds. Part of its build process seems to be automated, which is the least you could expect. Now here’s the thing: app signing keys are on an air-gapped server (meaning it’s disconnected from any network, at least that’s what they claim: see their recommendations for reference), which forces an irregular update cycle where a human has to manually trigger the signing process. It is far from an ideal situation, and you may argue it’s the least to be expected since by entrusting all the signing keys to one party, you could also introduce a single point of failure. Should their system be compromised (whether from the inside or the outside), this could lead to serious security issues affecting plenty of users.\nThis is one of the main reasons why Signal refused to support the inclusion of a third-party build in the F-Droid official repository. While this GitHub issue is quite old, many points still hold true today.\nConsidering all this, and the fact that their build process is often broken using outdated tools, you have to expect far slower updates compared to a traditional distribution system. Slow updates mean that you will be exposed to security vulnerabilities more often than you should’ve been. It would be unwise to have a full browser updated through the F-Droid official repository, for instance. F-Droid third-party repositories somewhat mitigate the issue of slow updates since they can be managed directly by the developer. It isn’t ideal either as you will see below.\n3. Low target API level (SDK) for client \u0026 apps SDK stands for Software Development Kit and is the collection of software to build apps for a given platform. On Android, a higher SDK level means you’ll be able to make use of modern API levels of which each iteration brings security and privacy improvements. For instance, API level 31 makes use of all these improvements on Android 12.\nAs you may already know, Android has a strong sandboxing model where each application is sandboxed. You could say that an app compiled with the highest API level benefits from all the latest improvements brought to the app sandbox; as opposed to outdated apps compiled with older API levels, which have a weaker sandbox.\n# b/35917228 - /proc/misc access # This will go away in a future Android release allow untrusted_app_25 proc_misc:file r_file_perms; # Access to /proc/tty/drivers, to allow apps to determine if they # are running in an emulated environment. # b/33214085 b/33814662 b/33791054 b/33211769 # https://github.com/strazzere/anti-emulator/blob/master/AntiEmulator/src/diff/strazzere/anti/emulator/FindEmulator.java # This will go away in a future Android release allow untrusted_app_25 proc_tty_drivers:file r_file_perms; This is a mere sample of the SELinux exceptions that have to be made on older API levels so that you can understand why it matters.\nIt turns out the official F-Droid client doesn’t care much about this since it lags behind quite a bit, targeting the API level 25 (Android 7.1) of which some SELinux exceptions were shown above. As a workaround, some users recommended third-party clients such as Foxy Droid or Aurora Droid. While these clients might be technically better, they’re poorly maintained for some, and they also introduce yet another party to the mix. Droid-ify (recently rebreanded to Neo-Store) seems to be a better option than the official client in most aspects.\nFurthermore, F-Droid doesn’t enforce a minimum target SDK for the official repository. Play Store does that quite aggressively for new apps and app updates:\nSince August 2021, Play Store requires new apps to target at least API level 30. Since November 2021, existing apps must at least target API level 30 for updates to be submitted. While it may seem bothersome, it’s a necessity to keep the app ecosystem modern and healthy. Here, F-Droid sends the wrong message to developers (and even users) because they should care about it, and this is why many of us think it may be even harmful to the FOSS ecosystem. Backward compatibility is often the enemy of security, and while there’s a middle-ground for convenience and obsolescence, it shouldn’t be exaggerated. As a result of this philosophy, the main repository of F-Droid is filled with obsolete apps from another era, just for these apps to be able to run on the more than ten years old Android 4.0 Ice Cream Sandwich. Let’s not make the same mistake as the desktop platforms: instead, complain to your vendors for selling devices with no decent OS/firmware support.\nThere is little practical reason for developers not to increase the target SDK version (targetSdkVersion) along with each Android release. This attribute matches the version of the platform an app is targeting, and allows access to modern improvements, rules and features on a modern OS. The app can still ensure backwards compatibility in such a way that it can run on older platforms: the minSdkVersion attribute informs the system about the minimum API level required for the application to run. Setting it too low isn’t practical though, because this requires having a lot of fallback code (most of it is handled by common libraries) and separate code paths.\nAt the time of writing:\nAndroid 9 is the oldest Android version that is getting security updates. ~80% of the Android devices used in the world are at least running 8.0 Oreo. Overall statistics do not reflect real-world usage of a given app (people using old devices are not necessarily using your app). If anything, it should be viewed as an underestimation.\n4. General lack of good practices The F-Droid client allows multiple repositories to coexist within the same app. Many of the issues highlighted above were focused on the main official repository which most of the F-Droid users will use anyway. However, having other repositories in a single app also violates the security model of Android which was not designed for this at all. The OS expects you to trust an app repository as a single source of apps, yet F-Droid isn’t that by design as it mixes several repositories in one single app. This is important because the OS management APIs and features (such as UserManager) are not meant for this and see F-Droid as a single source, so you’re trusting the app client to not mess up far more than you should, especially when the privileged extension comes into the picture. This is also a problem with the OS first-party source feature.\nOn that note, it is also worth noting the repository metadata format isn’t properly signed by lacking whole-file signing and key rotation. Their index v1 format uses JAR signing with jarsigner, which has serious security flaws. It seems that work is in progress on a v2 format with support for apksigner, although the final implementation remains to be seen. This just seems to be an over-engineered and flawed approach since better suited tools such as signify could be used to sign the metadata JSON.\nAs a matter of fact, the new unattended update API added in API level 31 (Android 12) that allows seamless app updates for app repositories without privileged access to the system (such an approach is not compatible with the security model) won’t work with F-Droid “as is”. It should be mentioned that the aforementioned third-party client Neo-Store supports this API, although the underlying issues about the F-Droid infrastructure largely remain. Indeed, this secure API allowing for unprivileged unattended updates not only requires for the app repository client to target API level 31, but the apps to be updated also have to at least target API level 29.\nTheir client also lacks TLS certificate pinning, unlike Play Store which improves security for all connections to Google (they generally use a limited set of root CAs including their own). Certificate pinning is a way for apps to increase the security of their connection to services by providing a set of public key hashes of known-good certificates for these services instead of trusting pre-installed CAs. This can avoid some cases where an interception (man-in-the-middle attack) could be possible and lead to various security issues considering you’re trusting the app to deliver you other apps.\nIt is an important security feature that is also straightforward to implement using the declarative network security configuration available since Android 7.0 (API level 24). See how GrapheneOS pins both root and CA certificates in their app repository client:\napps.grapheneos.org C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M= diGVwiVYbubAI3RW4hB9xU8e/CH2GnkuvVFZE8zmgzI= jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0= J2/oqMTsdhFWW/n85tys6b4yDBtb6idZayIEBx7QTxA= ... To be fair, they’ve thought several times about adding certificate pinning to their client at least for the default repositories. Relics of preliminary work can even be found in their current codebase, but it’s unfortunate that they haven’t been able to find any working implementation so far. Given the overly complex nature of F-Droid, that’s largely understandable.\nF-Droid also has a problem regarding the adoption of new signature schemes as they held out on the v1 signature scheme (which was horrible and deprecated since 2017) until they were forced by Android 11 requirements to support the newer v2/v3 schemes (v2 was introduced in Android 7.0). Quite frankly, this is straight-up bad, and signing APKs with GPG is no better considering how bad PGP and its reference implementation GPG are (even Debian is trying to move away from it). Ideally, F-Droid should fully move on to newer signature schemes, and should completely phase out the legacy signature schemes which are still being used for some apps and metadata.\n5. Confusing UX It is worth mentioning that their website has (for some reason) always been hosting an outdated APK of F-Droid, and this is still the case today, leading to many users wondering why they can’t install F-Droid on their secondary user profile (due to the downgrade prevention enforced by Android). “Stability” seems to be the main reason mentioned on their part, which doesn’t make sense: either your version isn’t ready to be published in a stable channel, or it is and new users should be able to access it easily.\nF-Droid should enforce the approach of prefixing the package name of their alternate builds with org.f-droid for instance (or add a .fdroid suffix as some already have). Building and signing while reusing the package name (application ID) is bad practice as it causes signature verification errors when some users try to update/install these apps from other sources, even directly from the developer. That is again due to the security model of Android which enforces a signature check when installing app updates (or installing them again in a secondary user profile). Note that this is going to be an issue with Play App Signing as well, and developers are encouraged to follow this approach should they intend to distribute their apps through different distribution channels.\nThis results in a confusing user experience where it’s hard to keep track of who signs each app, and from which repository the app should be downloaded or updated.\n6. Misleading permissions approach F-Droid shows a list of the low-level permissions for each app: these low-level permissions are usually grouped in the standard high-level permissions (Location, Microphone, Camera, etc.) and special toggles (nearby Wi-Fi networks, Bluetooth devices, etc.) that are explicitly based on a type of sensitive data. While showing a list of low-level permissions could be useful information for a developer, it’s often a misleading and inaccurate approach for the end-user. Since Android 6, apps have to request the standard permissions at runtime and do not get them simply by being installed, so showing all the “under the hood” permissions without proper context is not useful and makes the permission model unnecessarily confusing.\nF-Droid claims that these low-level permissions are relevant because they support Android 5.1+, meaning they support very outdated versions of Android where apps could have install-time permissions. Anyway, if a technical user wants to see all the manifest permissions for some reason, then they can access the app manifest pretty easily (in fact, exposing the raw manifest would be less misleading). But this is already beyond the scope of this article because anyone who cares about privacy and security wouldn’t run a 8 years old version of Android that has not received security updates for years.\nTo clear up confusion: even apps targeting an API level below 23 (Android 5.1 or older) do not have permissions granted at install time on modern Android, which instead displays a legacy permission grant dialog. Whether or not permissions are granted at install time does not just depend on the app’s targetSdkVersion. And even if this were the case, the OS package installer on modern Android would’ve been designed to show the requested permissions for those legacy apps.\nFor example, the low-level permission RECEIVE_BOOT_COMPLETED is referred to in F-Droid as the run at startup description, when in fact this permission is not needed to start at boot and just refers to a specific time broadcasted by the system once it finishes booting, and is not about background usage (though power usage may be a valid concern). To be fair, these short summaries used to be provided by the Android documentation years ago, but the permission model has drastically evolved since then and most of them aren’t accurate anymore.\nAllows the app to have itself started as soon as the system has finished booting. This can make it take longer to start the phone and allow the app to slow down the overall phone by always running.\nIn modern Android, the background restriction toggle is what really provides the ability for apps to run in the background. Some low-level permissions don’t even have a security/privacy impact and shouldn’t be misinterpreted as having one. Anyhow, you can be sure that each dangerous low-level permission has a high-level representation that is disabled by default and needs to be granted dynamically to the app (by a toggle or explicit user consent in general).\nAnother example to illustrate the shortcomings of this approach would be the QUERY_ALL_PACKAGES low-level permission, which is referred to as the query all packages permission that “allows an app to see all installed packages”. While this is somewhat correct, this can also be misleading: apps do not need QUERY_ALL_PACKAGES to list other apps within the same user profile. Even without this permission, some apps are visible automatically (visibility is restricted by default since Android 11). If an app needs more visibility, it will declare a element in its manifest file: in other words, QUERY_ALL_PACKAGES is only one way to achieve visibility. Again, this goes to show low-level manifest permissions are not intended to be interpreted as high-level permissions the user should fully comprehend.\nMoreover, Play Store restricts the use of highly invasive permissions such as MANAGE_EXTERNAL_STORAGE which allows apps to opt out of scoped storage if they can’t work with more privacy friendly approaches (like a file explorer). Apps that can’t justify their use of this permission (which again has to be granted dynamically) may be removed from Play Store. This is where an app repository can actually be useful in their review process to protect end-users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place…\nConclusion: what should you do? So far, you have been presented with referenced facts that are easily verifiable. In the next part, I’ll allow myself to express my own thoughts and opinions. You’re free to disagree with them, but don’t let that overshadow the rest.\nWhile some improvements could easily be made, I don’t think F-Droid is in an ideal situation to solve all of these issues because some of them are inherent flaws in their architecture. I’d also argue that their core philosophy is not aligned with some security principles expressed in this article. In any case, I can only wish for them to improve since they’re one of the most popular alternatives to commercial app repositories, and are therefore trusted by a large userbase.\nF-Droid is often seen as the only way to get and support open-source apps: that is not the case. Sure, F-Droid could help you in finding FOSS apps that you wouldn’t otherwise have known existed. Many developers also publish their FOSS apps on the Play Store or their website directly. Most of the time, releases are available on GitHub, which is great since each GitHub releases page has an Atom feed. If downloading APKs from regular websites, you can use apksigner to validate the authenticity by comparing the certificate fingerprint against the fingerprint from another source (it wouldn’t matter otherwise).\nThis is how you may proceed to get the app certificate:\napksigner verify --print-certs --verbose myCoolApp.apk Also, as written above: the OS pins the app signature (for all profiles) upon installation, and enforces signature check for app updates. In practice, this means the source doesn’t matter as much after the initial installation.\nFor most people, I’d recommend just sticking with Play Store. Play Store isn’t quite flawless, but emphasises the adoption of modern security standards which in turn encourages better privacy practices; as strange as it may sound, Google is not always doing bad things in that regard.\nNote: this article obviously can’t address all the flaws related to Play Store itself. Again, the main topic of this article is about F-Droid and should not be seen as an exhaustive comparison between different app repositories.\nShould I really care?\nIt’s up to your threat model, and of course your personal preferences. Most likely, your phone won’t turn into a nuclear weapon if you install F-Droid on it - and this is far from the point that this article is trying to make. Still, I believe the information presented will be valuable for anyone who values a practical approach to privacy (rather than an ideological one). Such an approach is partially described below.\nBut there is more malware in Play Store! How can you say that it’s more secure?\nAs explained above, it doesn’t matter as you shouldn’t really rely on any quality control to be the sole guarantee that a software is free of malicious or exploitable code. Play Store and even the Apple App Store may have a considerable amount of malware because a full reverse-engineering of any uploaded app isn’t feasible realistically. However, they fulfill their role quite well, and that is all that is expected of them.\nWith Play App Signing being effectively enforced for new apps, isn’t Play Store as “flawed” as F-Droid?\nI’ve seen this comment repeatedly, and it would be dismissing all the other points made in this article. Also, I strongly suggest that you carefully read the sections related to Play App Signing, and preferably the official documentation on this matter. It’s not a black and white question and there are many more nuances to it.\nAren’t open-source apps more secure? Doesn’t it make F-Droid safer?\nYou can still find and get your open-source apps elsewhere. And no, open-source apps aren’t necessarily more private or secure. Instead, you should rely on the strong security and privacy guarantees provided by a modern operating system with a robust sandboxing/permission model, namely modern Android, GrapheneOS and iOS. Pay close attention to the permissions you grant, and avoid legacy apps as they could require invasive permissions to run.\nWhen it comes to trackers (this really comes up a lot), you shouldn’t believe in the flawed idea that you can enumerate all of them. The enumerating badness approach is known to be flawed in the security field, and the same applies to privacy. You shouldn’t believe that a random script can detect every single line of code that can be used for data exfiltration. Data exfiltration can be properly prevented in the first place by the permission model, which again denies access to sensitive data by default: this is a simple, yet rigorous and effective approach.\nNo app should be unnecessarily entrusted with any kind of permission. It is only if you deem it necessary that you should allow access to a type of data, and this access should be as fine-grained as possible. That’s the way the Android platform works (regular apps run in the explicit untrusted_app domain) and continues evolving. Contrary to some popular beliefs, usability and most productivity tasks can still be achieved in a secure and private way.\nIsn’t Google evil? Isn’t Play Store spyware?\nSome people tend to exaggerate the importance of Google in their threat model, at the cost of pragmatism and security/privacy good practices. Play Store isn’t spyware and can run unprivileged like it does on GrapheneOS (including with unattended updates support). On the vast majority of devices though, Google Play is a privileged app and a core part of the OS that provides low-level system modules. In that case, the trust issues involved with Play App Signing could be considered less important since Google Play is already trusted as a privileged component.\nPlay Store evidently has some privacy issues given it’s a proprietary service which requires an account (this cannot be circumvented), and Google services have a history of nagging users to enable privacy-invasive features. Again, some of these privacy issues can be mitigated by setting up the Play services compatibility layer from GrapheneOS which runs Play services and Play Store in the regular app sandbox (the untrusted_app domain). ProtonAOSP also shares that feature. This solution could very well be ported to other Android-based operating systems. If you want to go further, consider using a properly configured account with the least amount of personally indentifiable information possible (note that the phone number requirement appears to be region-dependent).\nIf you don’t have Play services installed, you can use a third-party Play Store client called Aurora Store. Aurora Store has some issues of its own, and some of them overlap in fact with F-Droid. Aurora Store somehow still requires the legacy storage permission, has yet to implement certificate pinning, has been known to sometimes retrieve wrong versions of apps, and distributed account tokens over cleartext HTTP until fairly recently; not that it matters much since tokens were designed to be shared between users, which is already concerning. I’d recommend against using the shared “anonymous” accounts feature: you should make your own throwaway account with minimal information.\nYou should also keep an eye on the great work GrapheneOS does on their future app repository. It will be a simple, secure, modern app repository for a curated list of high-quality apps, some of which will have their own builds (for instance, Signal still uses their original 1024-bits RSA key that has never been rotated since then). Inspired by this work, a GrapheneOS community member is developing a more generic app repository called Accrescent. Hopefully, we’ll see well-made alternatives like these flourish.\nThanks to the GrapheneOS community for proofreading this article. Bear in mind that these are not official recommendations from the GrapheneOS project.\nPost-publication note: it’s unfortunate that the release of this article mostly triggered a negative response from the F-Droid team which prefers to dismiss this article on several occasions rather than bringing relevant counterpoints. Some of their core members are also involved in a harassment campaign towards projects and security researchers that do not share their views. While this article remains a technical one, there are definitely ethical concerns to take into consideration.\n","wordCount":"5298","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Wonderfall"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/apps/f-droid-security-analysis/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/apps/>Applications</a></div><h1 class=post-title>F-Droid Security Analysis</h1><div class=post-meta>25 min&nbsp;·&nbsp;5298 words&nbsp;·&nbsp;Wonderfall&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/content/apps/F-Droid%20Security%20Analysis.md rel="noopener noreferrer" target=_blank>Suggest Changes</a>
+The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else&rsquo;s work."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Applications","item":"https://privsec.dev/apps/"},{"@type":"ListItem","position":3,"name":"F-Droid Security Analysis","item":"https://privsec.dev/apps/f-droid-security-analysis/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"F-Droid Security Analysis","name":"F-Droid Security Analysis","description":"F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider.\nBefore we start, a few things to keep in mind:\nThe main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else\u0026rsquo;s work.","keywords":["software","android","security"],"articleBody":"F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider.\nBefore we start, a few things to keep in mind:\nThe main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else’s work. I have respect for any work done in the name of good intentions. Likewise, please don’t misinterpret the intentions of this article. You have your own reasons for using open-source or free/libre/whatever software which won’t be discussed here. A development model shouldn’t be an excuse for bad practices and shouldn’t lure you into believing that it can provide strong guarantees it cannot. A lot of information in this article is sourced from official and trusted sources, but you’re welcome to do your own research. These analyses do not account for threat models and personal preferences. As the author of this article, I’m only interested in facts and not ideologies. This is not an in-depth security review, nor is it exhaustive.\n1. The trusted party problem To understand why this is a problem, you’ll have to understand a bit about F-Droid’s architecture, the things it does very differently from other app repositories, and the Android platform security model (some of the issues listed in this article are somewhat out of the scope of the OS security model, but the majority is).\nUnlike other repositories, F-Droid signs all the apps in the main repository with its own signing keys (unique per app) at the exception of the very few reproducible builds. A signature is a mathematical scheme that guarantees the authenticity of the applications you download. Upon the installation of an app, Android pins the signature across the entire OS (including user profiles): that’s what we call a trust-on-first-use model since all subsequent updates of the app must have the corresponding signature to be installed.\nNormally, the developer is supposed to sign their own app prior to its upload on a distribution channel, whether that is a website or a traditional repository (or both). You don’t have to trust the source (usually recommended by the developer) except for the first installation: future updates will have their authenticity cryptographically guaranteed. The issue with F-Droid is that all apps are signed by the same party (F-Droid) which is also not the developer. You’re now adding another party you’ll have to trust since you still have to trust the developer anyway, which isn’t ideal: the fewer parties, the better.\nOn the other hand, Play Store now manages the app signing keys too, as Play App Signing is required for app bundles which are required for new apps since August 2021. These signing keys can be uploaded or automatically generated, and are securely stored by Google Cloud Key Management Service. It should be noted that the developer still has to sign the app with an upload key so that Google can verify its authenticity before signing it with the app signing key. For apps created before August 2021 that may have not opted in Play App Signing yet, the developer still manages the private key and is responsible for its security, as a compromised private key can allow a third party to sign and distribute malicious code.\nF-Droid requires that the source code of the app is exempt from any proprietary library or ad service, according to their inclusion policy. Usually, that means that some developers will have to maintain a slightly different version of their codebase that should comply with F-Droid’s requirements. Besides, their “quality control” offers close to no guarantees as having access to the source code doesn’t mean it can be easily proofread. Saying Play Store is filled with malicious apps is beyond the point: the false sense of security is a real issue. Users should not think of the F-Droid main repository as free of malicious apps, yet unfortunately many are inclined to believe this.\nBut… can’t I just trust F-Droid and be done with it?\nYou don’t have to take my word for it: they openly admit themselves it’s a very basic process relying on badness enumeration (this doesn’t work by the way) which consists in a few scripts scanning the code for proprietary blobs and known trackers. You are therefore not exempted from trusting upstream developers and it goes for any repository.\nA tempting idea would be to compare F-Droid to the desktop Linux model where users trust their distribution maintainers out-of-the-box (this can be sane if you’re already trusting the OS anyway), but the desktop platform is intrinsically chaotic and heterogeneous for better and for worse. It really shouldn’t be compared to the Android platform in any way.\nWhile we’ve seen that F-Droid controls the signing servers (much like Play App Signing), F-Droid also fully controls the build servers that run the disposable VMs used for building apps. And as of July 2022, their guest VM image officially runs a version of Debian which reached EOL. Undoubtedly, this raises questions about their whole infrastructure security.\nHow can you be sure that the app repository can be held to account for the code it delivers?\nF-Droid’s answer, interesting yet largely unused, is build reproducibility. While deterministic builds are a neat idea in theory, it requires the developer to make their toolchain match with what F-Droid provides. It’s additional work on both ends sometimes resulting in apps severely lagging behind in updates, so reproducible builds are not as common as we would have wanted. It should be noted that reproducible builds in the main repository can be exclusively developer-signed.\nGoogle’s approach is code transparency for app bundles, which is a simple idea addressing some of the concerns with Play App Signing. A JSON Web Token (JWT) signed by a key private to the developer is included in the app bundle before its upload to Play Store. This token contains a list of DEX files and native .so libraries and their hashes, allowing end-users to verify that the running code was built and signed by the app developer. Code transparency has known limitations, however: not all resources can be verified, and this verification can only be done manually since it’s not part of the Android platform itself (so requiring a code transparency file cannot be enforced by the OS right now). Despite its incompleteness, code transparency is still helpful, easy to implement, and thus something we should see more often as time goes by.\nWhat about other app repositories such as Amazon?\nTo my current knowledge, the Amazon Appstore has always been wrapping APKs with their own code (including their own trackers), and this means they were effectively resigning submitted APKs.\nIf you understood correctly the information above, Google can’t do this for apps that haven’t opted in Play App Signing. As for apps concerned by Play App Signing, while Google could technically introduce their own code like Amazon, they wouldn’t do that without telling about it since this will be easily noticeable by the developer and more globally researchers. They have other means on the Android app development platform to do so. Believing they won’t do that based on this principle is not a strong guarantee, however: hence the above paragraph about code transparency for app bundles.\nHuawei AppGallery seems to have a similar approach to Google, where submitted apps could be developer-signed, but newer apps will be resigned by Huawei.\n2. Slow and irregular updates Since you’re adding one more party to the mix, that party is now responsible for delivering proper builds of the app: it’s a common thing among traditional Linux distributions and their packaging system. They have to catch up with upstream on a regular basis, but very few do it well (Arch Linux comes to my mind). Others, like Debian, prefer making extensive downstream changes and delivering security fixes for a subset of vulnerabilities assigned to a CVE (yeah, it’s as bad as it sounds, but that’s another topic).\nNot only does F-Droid require specific changes for the app to comply with its inclusion policy, which often leads to more maintenance work, it also has a rather strange way of triggering new builds. Part of its build process seems to be automated, which is the least you could expect. Now here’s the thing: app signing keys are on an air-gapped server (meaning it’s disconnected from any network, at least that’s what they claim: see their recommendations for reference), which forces an irregular update cycle where a human has to manually trigger the signing process. It is far from an ideal situation, and you may argue it’s the least to be expected since by entrusting all the signing keys to one party, you could also introduce a single point of failure. Should their system be compromised (whether from the inside or the outside), this could lead to serious security issues affecting plenty of users.\nThis is one of the main reasons why Signal refused to support the inclusion of a third-party build in the F-Droid official repository. While this GitHub issue is quite old, many points still hold true today.\nConsidering all this, and the fact that their build process is often broken using outdated tools, you have to expect far slower updates compared to a traditional distribution system. Slow updates mean that you will be exposed to security vulnerabilities more often than you should’ve been. It would be unwise to have a full browser updated through the F-Droid official repository, for instance. F-Droid third-party repositories somewhat mitigate the issue of slow updates since they can be managed directly by the developer. It isn’t ideal either as you will see below.\n3. Low target API level (SDK) for client \u0026 apps SDK stands for Software Development Kit and is the collection of software to build apps for a given platform. On Android, a higher SDK level means you’ll be able to make use of modern API levels of which each iteration brings security and privacy improvements. For instance, API level 31 makes use of all these improvements on Android 12.\nAs you may already know, Android has a strong sandboxing model where each application is sandboxed. You could say that an app compiled with the highest API level benefits from all the latest improvements brought to the app sandbox; as opposed to outdated apps compiled with older API levels, which have a weaker sandbox.\n# b/35917228 - /proc/misc access # This will go away in a future Android release allow untrusted_app_25 proc_misc:file r_file_perms; # Access to /proc/tty/drivers, to allow apps to determine if they # are running in an emulated environment. # b/33214085 b/33814662 b/33791054 b/33211769 # https://github.com/strazzere/anti-emulator/blob/master/AntiEmulator/src/diff/strazzere/anti/emulator/FindEmulator.java # This will go away in a future Android release allow untrusted_app_25 proc_tty_drivers:file r_file_perms; This is a mere sample of the SELinux exceptions that have to be made on older API levels so that you can understand why it matters.\nIt turns out the official F-Droid client doesn’t care much about this since it lags behind quite a bit, targeting the API level 25 (Android 7.1) of which some SELinux exceptions were shown above. As a workaround, some users recommended third-party clients such as Foxy Droid or Aurora Droid. While these clients might be technically better, they’re poorly maintained for some, and they also introduce yet another party to the mix. Droid-ify (recently rebreanded to Neo-Store) seems to be a better option than the official client in most aspects.\nFurthermore, F-Droid doesn’t enforce a minimum target SDK for the official repository. Play Store does that quite aggressively for new apps and app updates:\nSince August 2021, Play Store requires new apps to target at least API level 30. Since November 2021, existing apps must at least target API level 30 for updates to be submitted. While it may seem bothersome, it’s a necessity to keep the app ecosystem modern and healthy. Here, F-Droid sends the wrong message to developers (and even users) because they should care about it, and this is why many of us think it may be even harmful to the FOSS ecosystem. Backward compatibility is often the enemy of security, and while there’s a middle-ground for convenience and obsolescence, it shouldn’t be exaggerated. As a result of this philosophy, the main repository of F-Droid is filled with obsolete apps from another era, just for these apps to be able to run on the more than ten years old Android 4.0 Ice Cream Sandwich. Let’s not make the same mistake as the desktop platforms: instead, complain to your vendors for selling devices with no decent OS/firmware support.\nThere is little practical reason for developers not to increase the target SDK version (targetSdkVersion) along with each Android release. This attribute matches the version of the platform an app is targeting, and allows access to modern improvements, rules and features on a modern OS. The app can still ensure backwards compatibility in such a way that it can run on older platforms: the minSdkVersion attribute informs the system about the minimum API level required for the application to run. Setting it too low isn’t practical though, because this requires having a lot of fallback code (most of it is handled by common libraries) and separate code paths.\nAt the time of writing:\nAndroid 9 is the oldest Android version that is getting security updates. ~80% of the Android devices used in the world are at least running 8.0 Oreo. Overall statistics do not reflect real-world usage of a given app (people using old devices are not necessarily using your app). If anything, it should be viewed as an underestimation.\n4. General lack of good practices The F-Droid client allows multiple repositories to coexist within the same app. Many of the issues highlighted above were focused on the main official repository which most of the F-Droid users will use anyway. However, having other repositories in a single app also violates the security model of Android which was not designed for this at all. The OS expects you to trust an app repository as a single source of apps, yet F-Droid isn’t that by design as it mixes several repositories in one single app. This is important because the OS management APIs and features (such as UserManager) are not meant for this and see F-Droid as a single source, so you’re trusting the app client to not mess up far more than you should, especially when the privileged extension comes into the picture. This is also a problem with the OS first-party source feature.\nOn that note, it is also worth noting the repository metadata format isn’t properly signed by lacking whole-file signing and key rotation. Their index v1 format uses JAR signing with jarsigner, which has serious security flaws. It seems that work is in progress on a v2 format with support for apksigner, although the final implementation remains to be seen. This just seems to be an over-engineered and flawed approach since better suited tools such as signify could be used to sign the metadata JSON.\nAs a matter of fact, the new unattended update API added in API level 31 (Android 12) that allows seamless app updates for app repositories without privileged access to the system (such an approach is not compatible with the security model) won’t work with F-Droid “as is”. It should be mentioned that the aforementioned third-party client Neo-Store supports this API, although the underlying issues about the F-Droid infrastructure largely remain. Indeed, this secure API allowing for unprivileged unattended updates not only requires for the app repository client to target API level 31, but the apps to be updated also have to at least target API level 29.\nTheir client also lacks TLS certificate pinning, unlike Play Store which improves security for all connections to Google (they generally use a limited set of root CAs including their own). Certificate pinning is a way for apps to increase the security of their connection to services by providing a set of public key hashes of known-good certificates for these services instead of trusting pre-installed CAs. This can avoid some cases where an interception (man-in-the-middle attack) could be possible and lead to various security issues considering you’re trusting the app to deliver you other apps.\nIt is an important security feature that is also straightforward to implement using the declarative network security configuration available since Android 7.0 (API level 24). See how GrapheneOS pins both root and CA certificates in their app repository client:\napps.grapheneos.org C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M= diGVwiVYbubAI3RW4hB9xU8e/CH2GnkuvVFZE8zmgzI= jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0= J2/oqMTsdhFWW/n85tys6b4yDBtb6idZayIEBx7QTxA= ... To be fair, they’ve thought several times about adding certificate pinning to their client at least for the default repositories. Relics of preliminary work can even be found in their current codebase, but it’s unfortunate that they haven’t been able to find any working implementation so far. Given the overly complex nature of F-Droid, that’s largely understandable.\nF-Droid also has a problem regarding the adoption of new signature schemes as they held out on the v1 signature scheme (which was horrible and deprecated since 2017) until they were forced by Android 11 requirements to support the newer v2/v3 schemes (v2 was introduced in Android 7.0). Quite frankly, this is straight-up bad, and signing APKs with GPG is no better considering how bad PGP and its reference implementation GPG are (even Debian is trying to move away from it). Ideally, F-Droid should fully move on to newer signature schemes, and should completely phase out the legacy signature schemes which are still being used for some apps and metadata.\n5. Confusing UX It is worth mentioning that their website has (for some reason) always been hosting an outdated APK of F-Droid, and this is still the case today, leading to many users wondering why they can’t install F-Droid on their secondary user profile (due to the downgrade prevention enforced by Android). “Stability” seems to be the main reason mentioned on their part, which doesn’t make sense: either your version isn’t ready to be published in a stable channel, or it is and new users should be able to access it easily.\nF-Droid should enforce the approach of prefixing the package name of their alternate builds with org.f-droid for instance (or add a .fdroid suffix as some already have). Building and signing while reusing the package name (application ID) is bad practice as it causes signature verification errors when some users try to update/install these apps from other sources, even directly from the developer. That is again due to the security model of Android which enforces a signature check when installing app updates (or installing them again in a secondary user profile). Note that this is going to be an issue with Play App Signing as well, and developers are encouraged to follow this approach should they intend to distribute their apps through different distribution channels.\nThis results in a confusing user experience where it’s hard to keep track of who signs each app, and from which repository the app should be downloaded or updated.\n6. Misleading permissions approach F-Droid shows a list of the low-level permissions for each app: these low-level permissions are usually grouped in the standard high-level permissions (Location, Microphone, Camera, etc.) and special toggles (nearby Wi-Fi networks, Bluetooth devices, etc.) that are explicitly based on a type of sensitive data. While showing a list of low-level permissions could be useful information for a developer, it’s often a misleading and inaccurate approach for the end-user. Since Android 6, apps have to request the standard permissions at runtime and do not get them simply by being installed, so showing all the “under the hood” permissions without proper context is not useful and makes the permission model unnecessarily confusing.\nF-Droid claims that these low-level permissions are relevant because they support Android 5.1+, meaning they support very outdated versions of Android where apps could have install-time permissions. Anyway, if a technical user wants to see all the manifest permissions for some reason, then they can access the app manifest pretty easily (in fact, exposing the raw manifest would be less misleading). But this is already beyond the scope of this article because anyone who cares about privacy and security wouldn’t run a 8 years old version of Android that has not received security updates for years.\nTo clear up confusion: even apps targeting an API level below 23 (Android 5.1 or older) do not have permissions granted at install time on modern Android, which instead displays a legacy permission grant dialog. Whether or not permissions are granted at install time does not just depend on the app’s targetSdkVersion. And even if this were the case, the OS package installer on modern Android would’ve been designed to show the requested permissions for those legacy apps.\nFor example, the low-level permission RECEIVE_BOOT_COMPLETED is referred to in F-Droid as the run at startup description, when in fact this permission is not needed to start at boot and just refers to a specific time broadcasted by the system once it finishes booting, and is not about background usage (though power usage may be a valid concern). To be fair, these short summaries used to be provided by the Android documentation years ago, but the permission model has drastically evolved since then and most of them aren’t accurate anymore.\nAllows the app to have itself started as soon as the system has finished booting. This can make it take longer to start the phone and allow the app to slow down the overall phone by always running.\nIn modern Android, the background restriction toggle is what really provides the ability for apps to run in the background. Some low-level permissions don’t even have a security/privacy impact and shouldn’t be misinterpreted as having one. Anyhow, you can be sure that each dangerous low-level permission has a high-level representation that is disabled by default and needs to be granted dynamically to the app (by a toggle or explicit user consent in general).\nAnother example to illustrate the shortcomings of this approach would be the QUERY_ALL_PACKAGES low-level permission, which is referred to as the query all packages permission that “allows an app to see all installed packages”. While this is somewhat correct, this can also be misleading: apps do not need QUERY_ALL_PACKAGES to list other apps within the same user profile. Even without this permission, some apps are visible automatically (visibility is restricted by default since Android 11). If an app needs more visibility, it will declare a element in its manifest file: in other words, QUERY_ALL_PACKAGES is only one way to achieve visibility. Again, this goes to show low-level manifest permissions are not intended to be interpreted as high-level permissions the user should fully comprehend.\nMoreover, Play Store restricts the use of highly invasive permissions such as MANAGE_EXTERNAL_STORAGE which allows apps to opt out of scoped storage if they can’t work with more privacy friendly approaches (like a file explorer). Apps that can’t justify their use of this permission (which again has to be granted dynamically) may be removed from Play Store. This is where an app repository can actually be useful in their review process to protect end-users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place…\nConclusion: what should you do? So far, you have been presented with referenced facts that are easily verifiable. In the next part, I’ll allow myself to express my own thoughts and opinions. You’re free to disagree with them, but don’t let that overshadow the rest.\nWhile some improvements could easily be made, I don’t think F-Droid is in an ideal situation to solve all of these issues because some of them are inherent flaws in their architecture. I’d also argue that their core philosophy is not aligned with some security principles expressed in this article. In any case, I can only wish for them to improve since they’re one of the most popular alternatives to commercial app repositories, and are therefore trusted by a large userbase.\nF-Droid is often seen as the only way to get and support open-source apps: that is not the case. Sure, F-Droid could help you in finding FOSS apps that you wouldn’t otherwise have known existed. Many developers also publish their FOSS apps on the Play Store or their website directly. Most of the time, releases are available on GitHub, which is great since each GitHub releases page has an Atom feed. If downloading APKs from regular websites, you can use apksigner to validate the authenticity by comparing the certificate fingerprint against the fingerprint from another source (it wouldn’t matter otherwise).\nThis is how you may proceed to get the app certificate:\napksigner verify --print-certs --verbose myCoolApp.apk Also, as written above: the OS pins the app signature (for all profiles) upon installation, and enforces signature check for app updates. In practice, this means the source doesn’t matter as much after the initial installation.\nFor most people, I’d recommend just sticking with Play Store. Play Store isn’t quite flawless, but emphasises the adoption of modern security standards which in turn encourages better privacy practices; as strange as it may sound, Google is not always doing bad things in that regard.\nNote: this article obviously can’t address all the flaws related to Play Store itself. Again, the main topic of this article is about F-Droid and should not be seen as an exhaustive comparison between different app repositories.\nShould I really care?\nIt’s up to your threat model, and of course your personal preferences. Most likely, your phone won’t turn into a nuclear weapon if you install F-Droid on it - and this is far from the point that this article is trying to make. Still, I believe the information presented will be valuable for anyone who values a practical approach to privacy (rather than an ideological one). Such an approach is partially described below.\nBut there is more malware in Play Store! How can you say that it’s more secure?\nAs explained above, it doesn’t matter as you shouldn’t really rely on any quality control to be the sole guarantee that a software is free of malicious or exploitable code. Play Store and even the Apple App Store may have a considerable amount of malware because a full reverse-engineering of any uploaded app isn’t feasible realistically. However, they fulfill their role quite well, and that is all that is expected of them.\nWith Play App Signing being effectively enforced for new apps, isn’t Play Store as “flawed” as F-Droid?\nI’ve seen this comment repeatedly, and it would be dismissing all the other points made in this article. Also, I strongly suggest that you carefully read the sections related to Play App Signing, and preferably the official documentation on this matter. It’s not a black and white question and there are many more nuances to it.\nAren’t open-source apps more secure? Doesn’t it make F-Droid safer?\nYou can still find and get your open-source apps elsewhere. And no, open-source apps aren’t necessarily more private or secure. Instead, you should rely on the strong security and privacy guarantees provided by a modern operating system with a robust sandboxing/permission model, namely modern Android, GrapheneOS and iOS. Pay close attention to the permissions you grant, and avoid legacy apps as they could require invasive permissions to run.\nWhen it comes to trackers (this really comes up a lot), you shouldn’t believe in the flawed idea that you can enumerate all of them. The enumerating badness approach is known to be flawed in the security field, and the same applies to privacy. You shouldn’t believe that a random script can detect every single line of code that can be used for data exfiltration. Data exfiltration can be properly prevented in the first place by the permission model, which again denies access to sensitive data by default: this is a simple, yet rigorous and effective approach.\nNo app should be unnecessarily entrusted with any kind of permission. It is only if you deem it necessary that you should allow access to a type of data, and this access should be as fine-grained as possible. That’s the way the Android platform works (regular apps run in the explicit untrusted_app domain) and continues evolving. Contrary to some popular beliefs, usability and most productivity tasks can still be achieved in a secure and private way.\nIsn’t Google evil? Isn’t Play Store spyware?\nSome people tend to exaggerate the importance of Google in their threat model, at the cost of pragmatism and security/privacy good practices. Play Store isn’t spyware and can run unprivileged like it does on GrapheneOS (including with unattended updates support). On the vast majority of devices though, Google Play is a privileged app and a core part of the OS that provides low-level system modules. In that case, the trust issues involved with Play App Signing could be considered less important since Google Play is already trusted as a privileged component.\nPlay Store evidently has some privacy issues given it’s a proprietary service which requires an account (this cannot be circumvented), and Google services have a history of nagging users to enable privacy-invasive features. Again, some of these privacy issues can be mitigated by setting up the Play services compatibility layer from GrapheneOS which runs Play services and Play Store in the regular app sandbox (the untrusted_app domain). ProtonAOSP also shares that feature. This solution could very well be ported to other Android-based operating systems. If you want to go further, consider using a properly configured account with the least amount of personally indentifiable information possible (note that the phone number requirement appears to be region-dependent).\nIf you don’t have Play services installed, you can use a third-party Play Store client called Aurora Store. Aurora Store has some issues of its own, and some of them overlap in fact with F-Droid. Aurora Store somehow still requires the legacy storage permission, has yet to implement certificate pinning, has been known to sometimes retrieve wrong versions of apps, and distributed account tokens over cleartext HTTP until fairly recently; not that it matters much since tokens were designed to be shared between users, which is already concerning. I’d recommend against using the shared “anonymous” accounts feature: you should make your own throwaway account with minimal information.\nYou should also keep an eye on the great work GrapheneOS does on their future app repository. It will be a simple, secure, modern app repository for a curated list of high-quality apps, some of which will have their own builds (for instance, Signal still uses their original 1024-bits RSA key that has never been rotated since then). Inspired by this work, a GrapheneOS community member is developing a more generic app repository called Accrescent. Hopefully, we’ll see well-made alternatives like these flourish.\nThanks to the GrapheneOS community for proofreading this article. Bear in mind that these are not official recommendations from the GrapheneOS project.\nPost-publication note: it’s unfortunate that the release of this article mostly triggered a negative response from the F-Droid team which prefers to dismiss this article on several occasions rather than bringing relevant counterpoints. Some of their core members are also involved in a harassment campaign towards projects and security researchers that do not share their views. While this article remains a technical one, there are definitely ethical concerns to take into consideration.\n","wordCount":"5298","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Wonderfall"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/apps/f-droid-security-analysis/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/apps/>Applications</a></div><h1 class=post-title>F-Droid Security Analysis</h1><div class=post-meta>25 min&nbsp;·&nbsp;5298 words&nbsp;·&nbsp;Wonderfall&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/blob/main/content/apps/F-Droid%20Security%20Analysis.md rel="noopener noreferrer" target=_blank>Suggest Changes</a>
 &nbsp;|&nbsp;<span>Originally published at&nbsp;<a href=https://wonderfall.dev/fdroid-issues title=https://wonderfall.dev/fdroid-issues target=_blank rel="noopener noreferrer">wonderfall.dev</a></span></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#1-the-trusted-party-problem aria-label="1. The trusted party problem">1. The trusted party problem</a></li><li><a href=#2-slow-and-irregular-updates aria-label="2. Slow and irregular updates">2. Slow and irregular updates</a></li><li><a href=#3-low-target-api-level-sdk-for-client--apps aria-label="3. Low target API level (SDK) for client &amp;amp; apps">3. Low target API level (SDK) for client & apps</a></li><li><a href=#4-general-lack-of-good-practices aria-label="4. General lack of good practices">4. General lack of good practices</a></li><li><a href=#5-confusing-ux aria-label="5. Confusing UX">5. Confusing UX</a></li><li><a href=#6-misleading-permissions-approach aria-label="6. Misleading permissions approach">6. Misleading permissions approach</a></li><li><a href=#conclusion-what-should-you-do aria-label="Conclusion: what should you do?">Conclusion: what should you do?</a></li></ul></div></details></div><div class=post-content><p>F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider.</p><p>Before we start, a few things to keep in mind:</p><ul><li>The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else&rsquo;s work. I have respect for any work done in the name of good intentions. Likewise, please don&rsquo;t misinterpret the intentions of this article.</li><li>You have your own reasons for using open-source or free/libre/whatever software which won&rsquo;t be discussed here. A development model shouldn&rsquo;t be an excuse for bad practices and shouldn&rsquo;t lure you into believing that it can provide strong guarantees it cannot.</li><li>A lot of information in this article is sourced from official and trusted sources, but you&rsquo;re welcome to do your own research.</li><li>These analyses do not account for threat models and personal preferences. As the author of this article, I&rsquo;m only interested in facts and not ideologies.</li></ul><p><em>This is not an in-depth security review, nor is it exhaustive.</em></p><h2 id=1-the-trusted-party-problem>1. The trusted party problem<a hidden class=anchor aria-hidden=true href=#1-the-trusted-party-problem>#</a></h2><p>To understand why this is a problem, you&rsquo;ll have to understand a bit about F-Droid&rsquo;s architecture, the things it does very differently from other app repositories, and the <a href=https://arxiv.org/pdf/1904.05572.pdf>Android platform security model</a> (some of the issues listed in this article are somewhat out of the scope of the OS security model, but the majority is).</p><p>Unlike other repositories, F-Droid signs all the apps in the main repository with <strong>its own signing keys</strong> (unique per app) at the exception of the very few <a href=https://f-droid.org/en/docs/Reproducible_Builds/>reproducible builds</a>. A signature is a mathematical scheme that guarantees the authenticity of the applications you download. Upon the installation of an app, Android pins the signature across the entire OS (including user profiles): that&rsquo;s what we call a <em>trust-on-first-use</em> model since all subsequent updates of the app must have the corresponding signature to be installed.</p><p>Normally, the developer is supposed to sign their own app prior to its upload on a distribution channel, whether that is a website or a traditional repository (or both). You don&rsquo;t have to trust the source (usually recommended by the developer) except for the first installation: future updates will have their authenticity cryptographically guaranteed. The issue with F-Droid is that all apps are signed by the same party (F-Droid) which is also not the developer. You&rsquo;re now adding another party you&rsquo;ll have to trust since <strong>you still have to trust the developer</strong> anyway, which isn&rsquo;t ideal: <strong>the fewer parties, the better</strong>.</p><p>On the other hand, Play Store now manages the app signing keys too, as <a href=https://developer.android.com/studio/publish/app-signing#app-signing-google-play>Play App Signing</a> is required for app bundles which are required for new apps since August 2021. These signing keys can be uploaded or automatically generated, and are securely stored by <a href=https://services.google.com/fh/files/misc/security_whitepapers_march2018.pdf>Google Cloud Key Management Service</a>. It should be noted that the developer still has to sign the app with <strong>an upload key</strong> so that Google can verify its authenticity before signing it with the app signing key. For apps created before August 2021 that may have <a href=https://developer.android.com/studio/publish/app-signing#opt-out>not opted in Play App Signing</a> yet, the developer still manages the private key and is responsible for its security, as a compromised private key can allow a third party to sign and distribute malicious code.</p><p>F-Droid requires that the source code of the app is exempt from any proprietary library or ad service, according to their <a href=https://f-droid.org/en/docs/Inclusion_Policy/>inclusion policy</a>. Usually, that means that some developers will have to maintain a slightly different version of their codebase that should comply with F-Droid&rsquo;s requirements. Besides, their &ldquo;quality control&rdquo; offers <strong>close to no guarantees</strong> as having access to the source code doesn&rsquo;t mean it can be easily proofread. Saying Play Store is filled with malicious apps is beyond the point: the <strong>false sense of security</strong> is a real issue. Users should not think of the F-Droid main repository as free of malicious apps, yet unfortunately many are inclined to believe this.</p><blockquote><p>But&mldr; can&rsquo;t I just trust F-Droid and be done with it?</p></blockquote><p><a href=https://forum.f-droid.org/t/is-it-as-safe-as-it-is-from-fdroid-official-repo/15956/12>You don&rsquo;t have to take my word for it</a>: they openly admit themselves it&rsquo;s a <a href=https://forum.f-droid.org/t/is-it-as-safe-as-it-is-from-fdroid-official-repo/15956/2>very basic process</a> relying on badness enumeration (this doesn&rsquo;t work by the way) which consists in a few scripts scanning the code for proprietary blobs and known trackers. You are therefore not exempted from trusting upstream developers and it goes for any repository.</p><p><em>A tempting idea would be to compare F-Droid to the desktop Linux model where users trust their distribution maintainers out-of-the-box (this can be sane if you&rsquo;re already trusting the OS anyway), but the desktop platform is intrinsically chaotic and heterogeneous for better and for worse. It really shouldn&rsquo;t be compared to the Android platform in any way.</em></p><p>While we&rsquo;ve seen that F-Droid controls the signing servers (much like Play App Signing), F-Droid also fully controls the build servers that run the disposable VMs used for building apps. And <a href=https://gitlab.com/groups/fdroid/-/milestones/5#tab-issues>as of July 2022</a>, their guest VM image officially runs a version of Debian which reached EOL. Undoubtedly, this raises questions about their whole infrastructure security.</p><blockquote><p>How can you be sure that the app repository can be held to account for the code it delivers?</p></blockquote><p>F-Droid&rsquo;s answer, interesting yet largely unused, is <a href=https://f-droid.org/en/docs/Reproducible_Builds/>build reproducibility</a>. While deterministic builds are a neat idea in theory, it requires the developer to make their toolchain match with what F-Droid provides. It&rsquo;s additional work on both ends sometimes resulting in <a href=https://code.briarproject.org/briar/briar/-/issues/1612>apps severely lagging behind in updates</a>, so reproducible builds are not as common as we would have wanted. It should be noted that reproducible builds in the main repository can be exclusively developer-signed.</p><p>Google&rsquo;s approach is <a href=https://developer.android.com/guide/app-bundle/code-transparency>code transparency for app bundles</a>, which is a simple idea addressing some of the concerns with Play App Signing. A JSON Web Token (JWT) signed by a key private to the developer is included in the app bundle before its upload to Play Store. This token contains a list of DEX files and native <code>.so</code> libraries and their hashes, allowing end-users to verify that the running code was built and signed by the app developer. Code transparency has known limitations, however: not all resources can be verified, and this verification can only be done manually since it&rsquo;s not part of the Android platform itself (so requiring a code transparency file cannot be enforced by the OS right now). Despite its incompleteness, code transparency is still helpful, easy to implement, and thus something we should see more often as time goes by.</p><blockquote><p>What about other app repositories such as Amazon?</p></blockquote><p><a href=https://developer.amazon.com/docs/app-submission/understanding-submission.html#code_wrapper>To my current knowledge</a>, the Amazon Appstore has always been wrapping APKs with their own code (including their own trackers), and this means they were effectively resigning submitted APKs.</p><p>If you understood correctly the information above, Google can&rsquo;t do this for apps that haven&rsquo;t opted in Play App Signing. As for apps concerned by Play App Signing, while Google could technically introduce their own code like Amazon, they wouldn&rsquo;t do that without telling about it since this will be easily noticeable by the developer and more globally researchers. They have other means on the Android app development platform to do so. Believing they won&rsquo;t do that based on this principle is not a strong guarantee, however: hence the above paragraph about code transparency for app bundles.</p><p>Huawei AppGallery seems to have a <a href=https://developer.huawei.com/consumer/en/doc/distribution/app/20210812>similar approach</a> to Google, where submitted apps could be developer-signed, but newer apps will be resigned by Huawei.</p><h2 id=2-slow-and-irregular-updates>2. Slow and irregular updates<a hidden class=anchor aria-hidden=true href=#2-slow-and-irregular-updates>#</a></h2><p>Since you&rsquo;re adding one more party to the mix, that party is now responsible for delivering proper builds of the app: it&rsquo;s a common thing among traditional Linux distributions and their packaging system. They have to catch up with <em>upstream</em> on a regular basis, but very few do it well (Arch Linux comes to my mind). Others, like Debian, prefer making extensive <em>downstream</em> changes and delivering security fixes for a subset of vulnerabilities assigned to a CVE (yeah, it&rsquo;s as bad as it sounds, but that&rsquo;s another topic).</p><p>Not only does F-Droid require specific changes for the app to comply with its inclusion policy, which often leads to more maintenance work, it also has a rather strange way of triggering new builds. Part of its build process seems to be <a href=https://f-droid.org/en/docs/FAQ_-_App_Developers/>automated</a>, which is the least you could expect. Now here&rsquo;s the thing: app signing keys are on an <strong>air-gapped server</strong> (meaning it&rsquo;s disconnected from any network, at least that&rsquo;s what they claim: see <a href=https://f-droid.org/docs/Building_a_Signing_Server/>their recommendations</a> for reference), which forces an irregular update cycle where a human has to manually trigger the signing process. It is far from an ideal situation, and you may argue it&rsquo;s the least to be expected since by entrusting all the signing keys to one party, you could also introduce a single point of failure. Should their system be compromised (whether from the inside or the outside), this could lead to serious security issues affecting plenty of users.</p><p><em>This is one of the main reasons why Signal refused to support the inclusion of a third-party build in the F-Droid official repository. While <a href=https://github.com/signalapp/Signal-Android/issues/127>this GitHub issue</a> is quite old, many points still hold true today.</em></p><p>Considering all this, and the fact that their build process is often broken using outdated tools, you have to expect <strong>far slower updates</strong> compared to a traditional distribution system. Slow updates mean that you will be exposed to security vulnerabilities more often than you should&rsquo;ve been. It would be unwise to have a full browser updated through the F-Droid official repository, for instance. F-Droid third-party repositories somewhat mitigate the issue of slow updates since they can be managed directly by the developer. It isn&rsquo;t ideal either as you will see below.</p><h2 id=3-low-target-api-level-sdk-for-client--apps>3. Low target API level (SDK) for client & apps<a hidden class=anchor aria-hidden=true href=#3-low-target-api-level-sdk-for-client--apps>#</a></h2><p>SDK stands for <em>Software Development Kit</em> and is the collection of software to build apps for a given platform. On Android, a higher SDK level means you&rsquo;ll be able to make use of modern API levels of which each iteration brings <strong>security and privacy improvements</strong>. For instance, API level 31 makes use of all these improvements on Android 12.</p><p>As you may already know, Android has a strong sandboxing model where each application is sandboxed. You could say that an app compiled with the highest API level benefits from all the latest improvements brought to the app sandbox; as opposed to outdated apps compiled with older API levels, which have a <strong>weaker sandbox</strong>.</p><pre tabindex=0><code># b/35917228 - /proc/misc access
 # This will go away in a future Android release
 allow untrusted_app_25 proc_misc:file r_file_perms;
diff --git a/public/donate/index.html b/public/donate/index.html
index 25b0901..c4fed09 100644
--- a/public/donate/index.html
+++ b/public/donate/index.html
@@ -1,5 +1,5 @@
 <!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>Donate | PrivSec.dev</title><meta name=keywords content><meta name=description content="The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project."><meta name=author content="PrivSec Team"><link rel=canonical href=https://privsec.dev/donate/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><script defer crossorigin=anonymous src=/assets/js/highlight.f413e19d0714851f6474e7ee9632408e58ac146fbdbe62747134bea2fa3415e0.js integrity="sha256-9BPhnQcUhR9kdOfuljJAjlisFG+9vmJ0cTS+ovo0FeA=" onload=hljs.initHighlightingOnLoad()></script>
-<link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="Donate"><meta property="og:description" content="The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project."><meta property="og:type" content="article"><meta property="og:url" content="https://privsec.dev/donate/"><meta property="article:section" content><meta name=twitter:card content="summary"><meta name=twitter:title content="Donate"><meta name=twitter:description content="The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Donate","item":"https://privsec.dev/donate/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Donate","name":"Donate","description":"The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project.","keywords":[],"articleBody":"The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project.\nThe real cost is the time and energy we put into writing, testing, and fact checking the content. Some of our members may want accept donation, and you can donate to them individually.\nJune XMR: 49b1PUPeHJEDwZqaaQm4MQUjycY8ckEko53jvTcPB5yE2QKoS5haNe3Fnbg1Le7nSkgUkm4tcpj4Z2YmtaT3j6KVUVgBGw2\nAlternatively, please consider donating to the projects below. These are projects which we rely on for our own digital safety and recommend to our readers. They are vital for the privacy, security, and safety of thousands of people.\nGrapheneOS Donation Link: grapheneos.org/donate\n","wordCount":"161","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"PrivSec Team"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/donate/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a></div><h1 class=post-title>Donate</h1><div class=post-meta>1 min&nbsp;·&nbsp;161 words&nbsp;·&nbsp;PrivSec Team&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/content/donate.md rel="noopener noreferrer" target=_blank>Suggest Changes</a></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#june aria-label=June>June</a></li><li><a href=#grapheneos aria-label=GrapheneOS>GrapheneOS</a></li></ul></div></details></div><div class=post-content><p>The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project.</p><p>The real cost is the time and energy we put into writing, testing, and fact checking the content. Some of our members may want accept donation, and you can donate to them individually.</p><h3 id=june>June<a hidden class=anchor aria-hidden=true href=#june>#</a></h3><p><strong>XMR</strong>: <code>49b1PUPeHJEDwZqaaQm4MQUjycY8ckEko53jvTcPB5yE2QKoS5haNe3Fnbg1Le7nSkgUkm4tcpj4Z2YmtaT3j6KVUVgBGw2</code></p><hr><p>Alternatively, please consider donating to the projects below. These are projects which we rely on for our own digital safety and recommend to our readers. They are vital for the privacy, security, and safety of thousands of people.</p><h3 id=grapheneos>GrapheneOS<a hidden class=anchor aria-hidden=true href=#grapheneos>#</a></h3><p><strong>Donation Link</strong>: <a href=https://grapheneos.org/donate>grapheneos.org/donate</a></p></div><footer class=post-footer><ul class=post-tags></ul></footer></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+<link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="Donate"><meta property="og:description" content="The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project."><meta property="og:type" content="article"><meta property="og:url" content="https://privsec.dev/donate/"><meta property="article:section" content><meta name=twitter:card content="summary"><meta name=twitter:title content="Donate"><meta name=twitter:description content="The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Donate","item":"https://privsec.dev/donate/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Donate","name":"Donate","description":"The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project.","keywords":[],"articleBody":"The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project.\nThe real cost is the time and energy we put into writing, testing, and fact checking the content. Some of our members may want accept donation, and you can donate to them individually.\nJune XMR: 49b1PUPeHJEDwZqaaQm4MQUjycY8ckEko53jvTcPB5yE2QKoS5haNe3Fnbg1Le7nSkgUkm4tcpj4Z2YmtaT3j6KVUVgBGw2\nAlternatively, please consider donating to the projects below. These are projects which we rely on for our own digital safety and recommend to our readers. They are vital for the privacy, security, and safety of thousands of people.\nGrapheneOS Donation Link: grapheneos.org/donate\n","wordCount":"161","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"PrivSec Team"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/donate/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a></div><h1 class=post-title>Donate</h1><div class=post-meta>1 min&nbsp;·&nbsp;161 words&nbsp;·&nbsp;PrivSec Team&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/blob/main/content/donate.md rel="noopener noreferrer" target=_blank>Suggest Changes</a></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#june aria-label=June>June</a></li><li><a href=#grapheneos aria-label=GrapheneOS>GrapheneOS</a></li></ul></div></details></div><div class=post-content><p>The domain costs us $12/year to renew from Google. We got our repository hosted for free on GitHub. We got our site hosted for free with Firebase. It costs Tommy ~$20/month to run the mail server, but that server is used for a bunch of his projects, not just PrivSec, and we doubt it will be used that much anyways. The point is, this website does not cost much to run, and as such we will not be accepting donation as a project.</p><p>The real cost is the time and energy we put into writing, testing, and fact checking the content. Some of our members may want accept donation, and you can donate to them individually.</p><h3 id=june>June<a hidden class=anchor aria-hidden=true href=#june>#</a></h3><p><strong>XMR</strong>: <code>49b1PUPeHJEDwZqaaQm4MQUjycY8ckEko53jvTcPB5yE2QKoS5haNe3Fnbg1Le7nSkgUkm4tcpj4Z2YmtaT3j6KVUVgBGw2</code></p><hr><p>Alternatively, please consider donating to the projects below. These are projects which we rely on for our own digital safety and recommend to our readers. They are vital for the privacy, security, and safety of thousands of people.</p><h3 id=grapheneos>GrapheneOS<a hidden class=anchor aria-hidden=true href=#grapheneos>#</a></h3><p><strong>Donation Link</strong>: <a href=https://grapheneos.org/donate>grapheneos.org/donate</a></p></div><footer class=post-footer><ul class=post-tags></ul></footer></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
         <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script><script>document.querySelectorAll("pre > code").forEach(e=>{const n=e.parentNode.parentNode,t=document.createElement("button");t.classList.add("copy-code"),t.innerHTML="copy";function s(){t.innerHTML="copied!",setTimeout(()=>{t.innerHTML="copy"},2e3)}t.addEventListener("click",t=>{if("clipboard"in navigator){navigator.clipboard.writeText(e.textContent),s();return}const n=document.createRange();n.selectNodeContents(e);const o=window.getSelection();o.removeAllRanges(),o.addRange(n);try{document.execCommand("copy"),s()}catch{}o.removeRange(n)}),n.classList.contains("highlight")?n.appendChild(t):n.parentNode.firstChild==n||(e.parentNode.parentNode.parentNode.parentNode.parentNode.nodeName=="TABLE"?e.parentNode.parentNode.parentNode.parentNode.parentNode.appendChild(t):e.parentNode.appendChild(t))})</script></body></html>
\ No newline at end of file
diff --git a/public/index.xml b/public/index.xml
index 180b218..2915abf 100644
--- a/public/index.xml
+++ b/public/index.xml
@@ -17,6 +17,17 @@ Tommy System Administrator. Benevolent dictator for life @privsec.dev.
 Website: tommytran.io</description>
     </item>
     
+    <item>
+      <title>Choosing Your Desktop Linux Distribution</title>
+      <link>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</link>
+      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
+      
+      <guid>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</guid>
+      <description>Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer.</description>
+    </item>
+    
     <item>
       <title>Docker and OCI Hardening</title>
       <link>https://privsec.dev/os/docker-and-oci-hardening/</link>
diff --git a/public/knowledge/index.html b/public/knowledge/index.html
index dde98fb..a67ca9f 100644
--- a/public/knowledge/index.html
+++ b/public/knowledge/index.html
@@ -1,6 +1,6 @@
 <!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>Knowledge Base | PrivSec.dev</title><meta name=keywords content><meta name=description content="Knowledge Base - PrivSec.dev"><meta name=author content="PrivSec Team"><link rel=canonical href=https://privsec.dev/knowledge/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><link rel=alternate type=application/rss+xml href=https://privsec.dev/knowledge/index.xml><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="Knowledge Base"><meta property="og:description" content><meta property="og:type" content="website"><meta property="og:url" content="https://privsec.dev/knowledge/"><meta name=twitter:card content="summary"><meta name=twitter:title content="Knowledge Base"><meta name=twitter:description content><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Knowledge Base","item":"https://privsec.dev/knowledge/"}]}</script></head><body class="list dark" id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span class=active>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><header class=page-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a></div><h1>Knowledge Base
 <a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class=post-entry><header class=entry-header><h2>Multi-factor Authentication</h2></header><div class=entry-content><p>Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.
-Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification....</p></div><footer class=entry-footer>6 min&nbsp;·&nbsp;1225 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Multi-factor Authentication" href=https://privsec.dev/knowledge/multi-factor-authentication/></a></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification....</p></div><footer class=entry-footer>6 min&nbsp;·&nbsp;1223 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Multi-factor Authentication" href=https://privsec.dev/knowledge/multi-factor-authentication/></a></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
         <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script></body></html>
\ No newline at end of file
diff --git a/public/knowledge/multi-factor-authentication/index.html b/public/knowledge/multi-factor-authentication/index.html
index 1a9c673..c4e74c6 100644
--- a/public/knowledge/multi-factor-authentication/index.html
+++ b/public/knowledge/multi-factor-authentication/index.html
@@ -2,7 +2,7 @@
 Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification."><meta name=author content="Tommy"><link rel=canonical href=https://privsec.dev/knowledge/multi-factor-authentication/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><script defer crossorigin=anonymous src=/assets/js/highlight.f413e19d0714851f6474e7ee9632408e58ac146fbdbe62747134bea2fa3415e0.js integrity="sha256-9BPhnQcUhR9kdOfuljJAjlisFG+9vmJ0cTS+ovo0FeA=" onload=hljs.initHighlightingOnLoad()></script>
 <link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="Multi-factor Authentication"><meta property="og:description" content="Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.
 Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification."><meta property="og:type" content="article"><meta property="og:url" content="https://privsec.dev/knowledge/multi-factor-authentication/"><meta property="article:section" content="knowledge"><meta name=twitter:card content="summary"><meta name=twitter:title content="Multi-factor Authentication"><meta name=twitter:description content="Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.
-Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Knowledge Base","item":"https://privsec.dev/knowledge/"},{"@type":"ListItem","position":3,"name":"Multi-factor Authentication","item":"https://privsec.dev/knowledge/multi-factor-authentication/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Multi-factor Authentication","name":"Multi-factor Authentication","description":"Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.\nCommon protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification.","keywords":["knowledge base","security"],"articleBody":"Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.\nCommon protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification. SMS on the other hand is problematic due to the lack of any kind of encryption, making it vulnerable to sniffing. Sim swap attacks, if carried out successfully, will allow an attacker to recieve your one time passcode while locking you out of your own account. In certain cases,websites or services may also allow the user to reset their account login by calling them using the phone number used for MFA, which could be faked with a spoofed CallerID.\nOnly use these protocols when it is the only option you have, and be very careful with SMS MFA as it could actually worsen your security.\nPush Confirmations Push confirmation MFA is typically a notification being sent to an app on your phone asking you to confirm new account logins. This method is a lot better than SMS or email, since an attacker typically wouldn’t be able to get these push notifications without having an already logged-in device.\nPush comfirmation in most cases rely on a third party provider like Duo. This means that trust is placed in a server that neither you nor your service provider control. A malicious push confirmation server could compromise your MFA or profile you based on which website and account you use with the service.\nEven if the push notification application and server is provided by first party as is the case with Microsoft login and Microsoft Authenticator, there is still a risk of you accidentally tapping on the confirmation button.\nTime-based One-time Password (TOTP) TOTP is one of the most common forms of MFA available. When you set up TOTP, you setup a “shared secret” with the service that you intend to use and store it in your authentication app.\nThe time-limited code is then derived from the shared secret and the current time. As the code is only valid for a short time, without access to the shared secret, an adversary cannot generate new codes.\nIf you have a Yubikey, you should store the “shared secrets” on the key itself using the Yubico Authenticator app. After the initial setup, the Yubico Authenticator will only expose the 6 digit code to the machine it is running on, but not the shared secret. Additional security can be set up by requiring touch confirmation, protecting digit codes not in used from a compromised operating system.\nUnlike WebAuthn, TOTP offers no protection against phishing or reuse attacks. If an adversary obtains a valid code from you, they may use it as many times as they like until it expires (generally 60 seconds + grace period).\nDespite of its short comings, TOTP is considered better and safer than Push Confirmations.\nYubico OTP Yubico OTP is an authentication protocol typically implemented in hardware security keys. When you decide to use Yubico OTP, the key will generate a public ID, private ID, and a Secret Key which is then uploaded to the Yubico OTP server.\nWhen logging into a website, all you need to do is to physically touch the security key. The security key will emulate a keyboard and print out a one-time password into the password field.\nThe service will then forward the one-time password to the Yubico OTP server for validation. A counter is incremented both on the key and Yubico’s validation server. The OTP can only be used once, and when a successful authentication occurs, the counter is increased which prevents reuse of the OTP. Yubico provides a detailed document about the process.\nThe Yubico validation server is a cloud based service, and you’re placing trust in Yubico that their server won’t be used to bypass your MFA or profile you. The public ID associated with Yubico OTP is reused on every website and could be another avenue for third-parties to profile you. Like TOTP, Yubico OTP does not provide phishing resistance.\nYubico OTP is an inferior protocol compared to TOTP since TOTP does not need trust in a third party server and most security keys that support Yubico OTP (namely the Yubikey and OnlyKey) supports TOTP anyway. Yubico OTP is still better than Push Confirmation, however.\nFIDO2 (Fast IDentity Online) FIDO includes a number of standards, first there was U2F and then later FIDO2 which includes the web standard WebAuthn.\nU2F and FIDO2 refer to the Client to Authenticator Protocol, which is the protocol between the security key and the computer, such as a laptop or phone. It complements WebAuthn which is the component used to authenticate with the website (the “Relying Party”) you’re trying to log in on.\nWebAuthn is the most secure and private form of second factor authentication. While the authentication experience is similar to Yubico OTP, the key does not print out a one-time password and validate with a third-party server. Instead, it uses public key cryptography for authentication.\nSince FIDO2/WebAuthn uses unique cryptographic keys with each internet site, a site pretending to be another one will not be able to get the correct response to the challenge for MFA, making FIDO2/Webauthn is invulnerable to phising. It is also because of this authentication mechanism that a physical FIDO2 security key is not identifiable across different services like Yubico OTP. Even better, FIDO2 uses a counter for each authentication, which would help with detecting cloned keys.\nIf a website or service supports WebAuthn for the authentication, it is highly recommended that you use it over any other form of MFA.\nNotes Initial Set Up When buying a security key, it is important that you change the default credentials, set up password protection for the key, and enable touch confirmation if your key supports it. Products such as the YubiKey have multiple interfaces with separate credentials for each one of them, so you should go over each interface and set up protection as well.\nBackups You should always have backups for your MFA method. Hardware security keys can get lost, stolen or simply stop working over time. It is recommended that you have a pair of hardware security keys with the same access to your accounts instead of just one.\nWhen using TOTP with an authenticator app, be sure to back up your recovery keys to an offline and encrypted storage device.\nWeakest MFA method You are only as secure as the weakest authentication method you use. For instance, it makes little sense to add SMS 2FA as an alternative MFA method if you are already using FIDO2. An adversary who can compromise your SMS 2FA will get into your account just as easily as if you didn’t use FIDO2 at all.\nThus, it is important to stick to the best authentication method you have acess to. It is better to have 2 Yubikeys for FIDO2 than 1 FIDO2 key and one authenticator app for TOTP. Likewise, it is better to have 1 TOTP instance and a backup key than to use TOTP alongside with Email or SMS 2FA.\n","wordCount":"1225","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Tommy"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/knowledge/multi-factor-authentication/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/knowledge/>Knowledge Base</a></div><h1 class=post-title>Multi-factor Authentication</h1><div class=post-meta>6 min&nbsp;·&nbsp;1225 words&nbsp;·&nbsp;Tommy&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/content/knowledge/Multi-factor%20Authentication.md rel="noopener noreferrer" target=_blank>Suggest Changes</a></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#common-protocols aria-label="Common protocols">Common protocols</a><ul><li><a href=#email-and-sms-mfa aria-label="Email and SMS MFA">Email and SMS MFA</a></li><li><a href=#push-confirmations aria-label="Push Confirmations">Push Confirmations</a></li><li><a href=#time-based-one-time-password-totp aria-label="Time-based One-time Password (TOTP)">Time-based One-time Password (TOTP)</a></li><li><a href=#yubico-otp aria-label="Yubico OTP">Yubico OTP</a></li><li><a href=#fido2-fast-identity-online aria-label="FIDO2 (Fast IDentity Online)">FIDO2 (Fast IDentity Online)</a></li></ul></li><li><a href=#notes aria-label=Notes>Notes</a><ul><li><a href=#initial-set-up aria-label="Initial Set Up">Initial Set Up</a></li><li><a href=#backups aria-label=Backups>Backups</a></li><li><a href=#weakest-mfa-method aria-label="Weakest MFA method">Weakest MFA method</a></li></ul></li></ul></div></details></div><div class=post-content><p><strong>Multi-factor authentication</strong> is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.</p><h2 id=common-protocols>Common protocols<a hidden class=anchor aria-hidden=true href=#common-protocols>#</a></h2><h3 id=email-and-sms-mfa>Email and SMS MFA<a hidden class=anchor aria-hidden=true href=#email-and-sms-mfa>#</a></h3><p>Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification. SMS on the other hand is problematic due to the lack of any kind of encryption, making it vulnerable to sniffing. <a href=https://en.wikipedia.org/wiki/SIM_swap_scam>Sim swap</a> attacks, if carried out successfully, will allow an attacker to recieve your one time passcode while locking you out of your own account. In certain cases,websites or services may also allow the user to reset their account login by calling them using the phone number used for MFA, which could be faked with a <a href=https://en.wikipedia.org/wiki/Caller_ID_spoofing>spoofed CallerID</a>.</p><p>Only use these protocols when it is the only option you have, and be very careful with SMS MFA as it could actually worsen your security.</p><h3 id=push-confirmations>Push Confirmations<a hidden class=anchor aria-hidden=true href=#push-confirmations>#</a></h3><p>Push confirmation MFA is typically a notification being sent to an app on your phone asking you to confirm new account logins. This method is a lot better than SMS or email, since an attacker typically wouldn&rsquo;t be able to get these push notifications without having an already logged-in device.</p><p>Push comfirmation in most cases rely on a third party provider like <a href=https://duo.com/>Duo</a>. This means that trust is placed in a server that neither you nor your service provider control. A malicious push confirmation server could compromise your MFA or profile you based on which website and account you use with the service.</p><p>Even if the push notification application and server is provided by first party as is the case with Microsoft login and <a href=https://www.microsoft.com/en-us/security/mobile-authenticator-app>Microsoft Authenticator</a>, there is still a risk of you accidentally tapping on the confirmation button.</p><h3 id=time-based-one-time-password-totp>Time-based One-time Password (TOTP)<a hidden class=anchor aria-hidden=true href=#time-based-one-time-password-totp>#</a></h3><p>TOTP is one of the most common forms of MFA available. When you set up TOTP, you setup a &ldquo;<a href=https://en.wikipedia.org/wiki/Shared_secret>shared secret</a>&rdquo; with the service that you intend to use and store it in your authentication app.</p><p>The time-limited code is then derived from the shared secret and the current time. As the code is only valid for a short time, without access to the shared secret, an adversary cannot generate new codes.</p><p>If you have a <a href=https://www.yubico.com/>Yubikey</a>, you should store the &ldquo;shared secrets&rdquo; on the key itself using the <a href=https://www.yubico.com/products/yubico-authenticator/>Yubico Authenticator</a> app. After the initial setup, the Yubico Authenticator will only expose the 6 digit code to the machine it is running on, but not the shared secret. Additional security can be set up by requiring touch confirmation, protecting digit codes not in used from a compromised operating system.</p><p>Unlike <a href=#fido-fast-identity-online>WebAuthn</a>, TOTP offers no protection against <a href=https://en.wikipedia.org/wiki/Phishing>phishing</a> or reuse attacks. If an adversary obtains a valid code from you, they may use it as many times as they like until it expires (generally 60 seconds + grace period).</p><p>Despite of its short comings, TOTP is considered better and safer than Push Confirmations.</p><h3 id=yubico-otp>Yubico OTP<a hidden class=anchor aria-hidden=true href=#yubico-otp>#</a></h3><p>Yubico OTP is an authentication protocol typically implemented in hardware security keys. When you decide to use Yubico OTP, the key will generate a public ID, private ID, and a Secret Key which is then uploaded to the Yubico OTP server.</p><p>When logging into a website, all you need to do is to physically touch the security key. The security key will emulate a keyboard and print out a one-time password into the password field.</p><p>The service will then forward the one-time password to the Yubico OTP server for validation. A counter is incremented both on the key and Yubico&rsquo;s validation server. The OTP can only be used once, and when a successful authentication occurs, the counter is increased which prevents reuse of the OTP. Yubico provides a <a href=https://developers.yubico.com/OTP/OTPs_Explained.html>detailed document</a> about the process.</p><p><img loading=lazy src=/yubico-otp.png alt="Yubico OTP"></p><p>The Yubico validation server is a cloud based service, and you&rsquo;re placing trust in Yubico that their server won&rsquo;t be used to bypass your MFA or profile you. The public ID associated with Yubico OTP is reused on every website and could be another avenue for third-parties to profile you. Like TOTP, Yubico OTP does not provide phishing resistance.</p><p>Yubico OTP is an inferior protocol compared to TOTP since TOTP does not need trust in a third party server and most security keys that support Yubico OTP (namely the Yubikey and OnlyKey) supports TOTP anyway. Yubico OTP is still better than Push Confirmation, however.</p><h3 id=fido2-fast-identity-online>FIDO2 (Fast IDentity Online)<a hidden class=anchor aria-hidden=true href=#fido2-fast-identity-online>#</a></h3><p><a href=https://en.wikipedia.org/wiki/FIDO_Alliance>FIDO</a> includes a number of standards, first there was U2F and then later <a href=https://en.wikipedia.org/wiki/FIDO2_Project>FIDO2</a> which includes the web standard <a href=https://en.wikipedia.org/wiki/WebAuthn>WebAuthn</a>.</p><p>U2F and FIDO2 refer to the <a href=https://en.wikipedia.org/wiki/Client_to_Authenticator_Protocol>Client to Authenticator Protocol</a>, which is the protocol between the security key and the computer, such as a laptop or phone. It complements WebAuthn which is the component used to authenticate with the website (the &ldquo;Relying Party&rdquo;) you&rsquo;re trying to log in on.</p><p>WebAuthn is the most secure and private form of second factor authentication. While the authentication experience is similar to Yubico OTP, the key does not print out a one-time password and validate with a third-party server. Instead, it uses <a href=https://en.wikipedia.org/wiki/Public-key_cryptography>public key cryptography</a> for authentication.</p><div style=position:relative;padding-bottom:56.25%;height:0;overflow:hidden><iframe src=https://www.youtube-nocookie.com/embed/aMo4ZlWznao style=position:absolute;top:0;left:0;width:100%;height:100%;border:0 allowfullscreen title="YouTube Video"></iframe></div><p>Since FIDO2/WebAuthn uses unique cryptographic keys with each internet site, a site pretending to be another one will not be able to get the correct response to the challenge for MFA, making FIDO2/Webauthn is invulnerable to phising. It is also because of this authentication mechanism that a physical FIDO2 security key is not identifiable across different services like Yubico OTP. Even better, FIDO2 uses a counter for each authentication, which would help with detecting cloned keys.</p><p>If a website or service supports WebAuthn for the authentication, it is highly recommended that you use it over any other form of MFA.</p><h2 id=notes>Notes<a hidden class=anchor aria-hidden=true href=#notes>#</a></h2><h3 id=initial-set-up>Initial Set Up<a hidden class=anchor aria-hidden=true href=#initial-set-up>#</a></h3><p>When buying a security key, it is important that you change the default credentials, set up password protection for the key, and enable touch confirmation if your key supports it. Products such as the YubiKey have multiple interfaces with separate credentials for each one of them, so you should go over each interface and set up protection as well.</p><h3 id=backups>Backups<a hidden class=anchor aria-hidden=true href=#backups>#</a></h3><p>You should always have backups for your MFA method. Hardware security keys can get lost, stolen or simply stop working over time. It is recommended that you have a pair of hardware security keys with the same access to your accounts instead of just one.</p><p>When using TOTP with an authenticator app, be sure to back up your recovery keys to an offline and encrypted storage device.</p><h3 id=weakest-mfa-method>Weakest MFA method<a hidden class=anchor aria-hidden=true href=#weakest-mfa-method>#</a></h3><p>You are only as secure as the weakest authentication method you use. For instance, it makes little sense to add SMS 2FA as an alternative MFA method if you are already using FIDO2. An adversary who can compromise your SMS 2FA will get into your account just as easily as if you didn&rsquo;t use FIDO2 at all.</p><p>Thus, it is important to stick to the best authentication method you have acess to. It is better to have 2 Yubikeys for FIDO2 than 1 FIDO2 key and one authenticator app for TOTP. Likewise, it is better to have 1 TOTP instance and a backup key than to use TOTP alongside with Email or SMS 2FA.</p></div><footer class=post-footer><ul class=post-tags><li><a href=https://privsec.dev/tags/knowledge-base/>knowledge base</a></li><li><a href=https://privsec.dev/tags/security/>security</a></li></ul></footer></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Knowledge Base","item":"https://privsec.dev/knowledge/"},{"@type":"ListItem","position":3,"name":"Multi-factor Authentication","item":"https://privsec.dev/knowledge/multi-factor-authentication/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Multi-factor Authentication","name":"Multi-factor Authentication","description":"Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.\nCommon protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification.","keywords":["knowledge base","security"],"articleBody":"Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.\nCommon protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification. SMS on the other hand is problematic due to the lack of any kind of encryption, making it vulnerable to sniffing. Sim swap attacks, if carried out successfully, will allow an attacker to recieve your one time passcode while locking you out of your own account. In certain cases,websites or services may also allow the user to reset their account login by calling them using the phone number used for MFA, which could be faked with a spoofed CallerID.\nOnly use these protocols when it is the only option you have, and be very careful with SMS MFA as it could actually worsen your security.\nPush Confirmations Push confirmation MFA is typically a notification being sent to an app on your phone asking you to confirm new account logins. This method is a lot better than SMS or email, since an attacker typically wouldn’t be able to get these push notifications without having an already logged-in device.\nPush comfirmation in most cases rely on a third party provider like Duo. This means that trust is placed in a server that neither you nor your service provider control. A malicious push confirmation server could compromise your MFA or profile you based on which website and account you use with the service.\nEven if the push notification application and server is provided by first party as is the case with Microsoft login and Microsoft Authenticator, there is still a risk of you accidentally tapping on the confirmation button.\nTime-based One-time Password (TOTP) TOTP is one of the most common forms of MFA available. When you set up TOTP, you setup a “shared secret” with the service that you intend to use and store it in your authentication app.\nThe time-limited code is then derived from the shared secret and the current time. As the code is only valid for a short time, without access to the shared secret, an adversary cannot generate new codes.\nIf you have a Yubikey, you should store the “shared secrets” on the key itself using the Yubico Authenticator app. After the initial setup, the Yubico Authenticator will only expose the 6 digit code to the machine it is running on, but not the shared secret. Additional security can be set up by requiring touch confirmation, protecting digit codes not in used from a compromised operating system.\nUnlike WebAuthn, TOTP offers no protection against phishing or reuse attacks. If an adversary obtains a valid code from you, they may use it as many times as they like until it expires (generally 60 seconds + grace period).\nDespite of its short comings, we consider TOTP better and safer than Push Confirmations.\nYubico OTP Yubico OTP is an authentication protocol typically implemented in hardware security keys. When you decide to use Yubico OTP, the key will generate a public ID, private ID, and a Secret Key which is then uploaded to the Yubico OTP server.\nWhen logging into a website, all you need to do is to physically touch the security key. The security key will emulate a keyboard and print out a one-time password into the password field.\nThe service will then forward the one-time password to the Yubico OTP server for validation. A counter is incremented both on the key and Yubico’s validation server. The OTP can only be used once, and when a successful authentication occurs, the counter is increased which prevents reuse of the OTP. Yubico provides a detailed document about the process.\nThe Yubico validation server is a cloud based service, and you’re placing trust in Yubico that their server won’t be used to bypass your MFA or profile you. The public ID associated with Yubico OTP is reused on every website and could be another avenue for third-parties to profile you. Like TOTP, Yubico OTP does not provide phishing resistance.\nYubico OTP is an inferior protocol compared to TOTP since TOTP does not need trust in a third party server and most security keys that support Yubico OTP (namely the Yubikey and OnlyKey) supports TOTP anyway. Yubico OTP is still better than Push Confirmation, however.\nFIDO2 (Fast IDentity Online) FIDO includes a number of standards, first there was U2F and then later FIDO2 which includes the web standard WebAuthn.\nU2F and FIDO2 refer to the Client to Authenticator Protocol, which is the protocol between the security key and the computer, such as a laptop or phone. It complements WebAuthn which is the component used to authenticate with the website (the “Relying Party”) you’re trying to log in on.\nWebAuthn is the most secure and private form of second factor authentication. While the authentication experience is similar to Yubico OTP, the key does not print out a one-time password and validate with a third-party server. Instead, it uses public key cryptography for authentication.\nSince FIDO2/WebAuthn uses unique cryptographic keys with each internet site, a site pretending to be another one will not be able to get the correct response to the challenge for MFA, making FIDO2/Webauthn is invulnerable phising. It is also because of this authentication mechanism that a physical FIDO2 security key is not identifiable across different services like Yubico OTP. Even better, FIDO2 uses a counter for each authentication, which would help with detecting cloned keys.\nIf a website or service supports WebAuthn for the authentication, it is highly recommended that you use it over any other form of MFA.\nNotes Initial Set Up When buying a security key, it is important that you change the default credentials, set up password protection for the key, and enable touch confirmation if your key supports it. Products such as the YubiKey have multiple interfaces with separate credentials for each one of them, so you should go over each interface and set up protection as well.\nBackups You should always have backups for your MFA method. Hardware security keys can get lost, stolen or simply stop working over time. It is recommended that you have a pair of hardware security keys with the same access to your accounts instead of just one.\nWhen using TOTP with an authenticator app, be sure to back up your recovery keys to an offline and encrypted storage device.\nWeakest link You are only as secure as the weakest authentication method you use. For instance, it makes little sense to add SMS 2FA as an alternative MFA method if you are already using FIDO2. An adversary who can compromise your SMS 2FA will get into your account just as easily as if you didn’t use FIDO2 at all.\nThus, it is important to stick to the best authentication method you have acess to. It is better to have 2 Yubikeys for FIDO2 than 1 FIDO2 key and one authenticator app for TOTP. Likewise, it is better to have 1 TOTP instance and a backup key than to use TOTP alongside with Email or SMS 2FA.\n","wordCount":"1223","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Tommy"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/knowledge/multi-factor-authentication/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/knowledge/>Knowledge Base</a></div><h1 class=post-title>Multi-factor Authentication</h1><div class=post-meta>6 min&nbsp;·&nbsp;1223 words&nbsp;·&nbsp;Tommy&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/blob/main/content/knowledge/Multi-factor%20Authentication.md rel="noopener noreferrer" target=_blank>Suggest Changes</a></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#common-protocols aria-label="Common protocols">Common protocols</a><ul><li><a href=#email-and-sms-mfa aria-label="Email and SMS MFA">Email and SMS MFA</a></li><li><a href=#push-confirmations aria-label="Push Confirmations">Push Confirmations</a></li><li><a href=#time-based-one-time-password-totp aria-label="Time-based One-time Password (TOTP)">Time-based One-time Password (TOTP)</a></li><li><a href=#yubico-otp aria-label="Yubico OTP">Yubico OTP</a></li><li><a href=#fido2-fast-identity-online aria-label="FIDO2 (Fast IDentity Online)">FIDO2 (Fast IDentity Online)</a></li></ul></li><li><a href=#notes aria-label=Notes>Notes</a><ul><li><a href=#initial-set-up aria-label="Initial Set Up">Initial Set Up</a></li><li><a href=#backups aria-label=Backups>Backups</a></li><li><a href=#weakest-link aria-label="Weakest link">Weakest link</a></li></ul></li></ul></div></details></div><div class=post-content><p><strong>Multi-factor authentication</strong> is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.</p><h2 id=common-protocols>Common protocols<a hidden class=anchor aria-hidden=true href=#common-protocols>#</a></h2><h3 id=email-and-sms-mfa>Email and SMS MFA<a hidden class=anchor aria-hidden=true href=#email-and-sms-mfa>#</a></h3><p>Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification. SMS on the other hand is problematic due to the lack of any kind of encryption, making it vulnerable to sniffing. <a href=https://en.wikipedia.org/wiki/SIM_swap_scam>Sim swap</a> attacks, if carried out successfully, will allow an attacker to recieve your one time passcode while locking you out of your own account. In certain cases,websites or services may also allow the user to reset their account login by calling them using the phone number used for MFA, which could be faked with a <a href=https://en.wikipedia.org/wiki/Caller_ID_spoofing>spoofed CallerID</a>.</p><p>Only use these protocols when it is the only option you have, and be very careful with SMS MFA as it could actually worsen your security.</p><h3 id=push-confirmations>Push Confirmations<a hidden class=anchor aria-hidden=true href=#push-confirmations>#</a></h3><p>Push confirmation MFA is typically a notification being sent to an app on your phone asking you to confirm new account logins. This method is a lot better than SMS or email, since an attacker typically wouldn&rsquo;t be able to get these push notifications without having an already logged-in device.</p><p>Push comfirmation in most cases rely on a third party provider like <a href=https://duo.com/>Duo</a>. This means that trust is placed in a server that neither you nor your service provider control. A malicious push confirmation server could compromise your MFA or profile you based on which website and account you use with the service.</p><p>Even if the push notification application and server is provided by first party as is the case with Microsoft login and <a href=https://www.microsoft.com/en-us/security/mobile-authenticator-app>Microsoft Authenticator</a>, there is still a risk of you accidentally tapping on the confirmation button.</p><h3 id=time-based-one-time-password-totp>Time-based One-time Password (TOTP)<a hidden class=anchor aria-hidden=true href=#time-based-one-time-password-totp>#</a></h3><p>TOTP is one of the most common forms of MFA available. When you set up TOTP, you setup a &ldquo;<a href=https://en.wikipedia.org/wiki/Shared_secret>shared secret</a>&rdquo; with the service that you intend to use and store it in your authentication app.</p><p>The time-limited code is then derived from the shared secret and the current time. As the code is only valid for a short time, without access to the shared secret, an adversary cannot generate new codes.</p><p>If you have a <a href=https://www.yubico.com/>Yubikey</a>, you should store the &ldquo;shared secrets&rdquo; on the key itself using the <a href=https://www.yubico.com/products/yubico-authenticator/>Yubico Authenticator</a> app. After the initial setup, the Yubico Authenticator will only expose the 6 digit code to the machine it is running on, but not the shared secret. Additional security can be set up by requiring touch confirmation, protecting digit codes not in used from a compromised operating system.</p><p>Unlike <a href=#fido-fast-identity-online>WebAuthn</a>, TOTP offers no protection against <a href=https://en.wikipedia.org/wiki/Phishing>phishing</a> or reuse attacks. If an adversary obtains a valid code from you, they may use it as many times as they like until it expires (generally 60 seconds + grace period).</p><p>Despite of its short comings, we consider TOTP better and safer than Push Confirmations.</p><h3 id=yubico-otp>Yubico OTP<a hidden class=anchor aria-hidden=true href=#yubico-otp>#</a></h3><p>Yubico OTP is an authentication protocol typically implemented in hardware security keys. When you decide to use Yubico OTP, the key will generate a public ID, private ID, and a Secret Key which is then uploaded to the Yubico OTP server.</p><p>When logging into a website, all you need to do is to physically touch the security key. The security key will emulate a keyboard and print out a one-time password into the password field.</p><p>The service will then forward the one-time password to the Yubico OTP server for validation. A counter is incremented both on the key and Yubico&rsquo;s validation server. The OTP can only be used once, and when a successful authentication occurs, the counter is increased which prevents reuse of the OTP. Yubico provides a <a href=https://developers.yubico.com/OTP/OTPs_Explained.html>detailed document</a> about the process.</p><p><img loading=lazy src=/yubico-otp.png alt="Yubico OTP"></p><p>The Yubico validation server is a cloud based service, and you&rsquo;re placing trust in Yubico that their server won&rsquo;t be used to bypass your MFA or profile you. The public ID associated with Yubico OTP is reused on every website and could be another avenue for third-parties to profile you. Like TOTP, Yubico OTP does not provide phishing resistance.</p><p>Yubico OTP is an inferior protocol compared to TOTP since TOTP does not need trust in a third party server and most security keys that support Yubico OTP (namely the Yubikey and OnlyKey) supports TOTP anyway. Yubico OTP is still better than Push Confirmation, however.</p><h3 id=fido2-fast-identity-online>FIDO2 (Fast IDentity Online)<a hidden class=anchor aria-hidden=true href=#fido2-fast-identity-online>#</a></h3><p><a href=https://en.wikipedia.org/wiki/FIDO_Alliance>FIDO</a> includes a number of standards, first there was U2F and then later <a href=https://en.wikipedia.org/wiki/FIDO2_Project>FIDO2</a> which includes the web standard <a href=https://en.wikipedia.org/wiki/WebAuthn>WebAuthn</a>.</p><p>U2F and FIDO2 refer to the <a href=https://en.wikipedia.org/wiki/Client_to_Authenticator_Protocol>Client to Authenticator Protocol</a>, which is the protocol between the security key and the computer, such as a laptop or phone. It complements WebAuthn which is the component used to authenticate with the website (the &ldquo;Relying Party&rdquo;) you&rsquo;re trying to log in on.</p><p>WebAuthn is the most secure and private form of second factor authentication. While the authentication experience is similar to Yubico OTP, the key does not print out a one-time password and validate with a third-party server. Instead, it uses <a href=https://en.wikipedia.org/wiki/Public-key_cryptography>public key cryptography</a> for authentication.</p><div style=position:relative;padding-bottom:56.25%;height:0;overflow:hidden><iframe src=https://www.youtube-nocookie.com/embed/aMo4ZlWznao style=position:absolute;top:0;left:0;width:100%;height:100%;border:0 allowfullscreen title="YouTube Video"></iframe></div><p>Since FIDO2/WebAuthn uses unique cryptographic keys with each internet site, a site pretending to be another one will not be able to get the correct response to the challenge for MFA, making FIDO2/Webauthn is invulnerable phising. It is also because of this authentication mechanism that a physical FIDO2 security key is not identifiable across different services like Yubico OTP. Even better, FIDO2 uses a counter for each authentication, which would help with detecting cloned keys.</p><p>If a website or service supports WebAuthn for the authentication, it is highly recommended that you use it over any other form of MFA.</p><h2 id=notes>Notes<a hidden class=anchor aria-hidden=true href=#notes>#</a></h2><h3 id=initial-set-up>Initial Set Up<a hidden class=anchor aria-hidden=true href=#initial-set-up>#</a></h3><p>When buying a security key, it is important that you change the default credentials, set up password protection for the key, and enable touch confirmation if your key supports it. Products such as the YubiKey have multiple interfaces with separate credentials for each one of them, so you should go over each interface and set up protection as well.</p><h3 id=backups>Backups<a hidden class=anchor aria-hidden=true href=#backups>#</a></h3><p>You should always have backups for your MFA method. Hardware security keys can get lost, stolen or simply stop working over time. It is recommended that you have a pair of hardware security keys with the same access to your accounts instead of just one.</p><p>When using TOTP with an authenticator app, be sure to back up your recovery keys to an offline and encrypted storage device.</p><h3 id=weakest-link>Weakest link<a hidden class=anchor aria-hidden=true href=#weakest-link>#</a></h3><p>You are only as secure as the weakest authentication method you use. For instance, it makes little sense to add SMS 2FA as an alternative MFA method if you are already using FIDO2. An adversary who can compromise your SMS 2FA will get into your account just as easily as if you didn&rsquo;t use FIDO2 at all.</p><p>Thus, it is important to stick to the best authentication method you have acess to. It is better to have 2 Yubikeys for FIDO2 than 1 FIDO2 key and one authenticator app for TOTP. Likewise, it is better to have 1 TOTP instance and a backup key than to use TOTP alongside with Email or SMS 2FA.</p></div><footer class=post-footer><ul class=post-tags><li><a href=https://privsec.dev/tags/knowledge-base/>knowledge base</a></li><li><a href=https://privsec.dev/tags/security/>security</a></li></ul></footer></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
         <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script><script>document.querySelectorAll("pre > code").forEach(e=>{const n=e.parentNode.parentNode,t=document.createElement("button");t.classList.add("copy-code"),t.innerHTML="copy";function s(){t.innerHTML="copied!",setTimeout(()=>{t.innerHTML="copy"},2e3)}t.addEventListener("click",t=>{if("clipboard"in navigator){navigator.clipboard.writeText(e.textContent),s();return}const n=document.createRange();n.selectNodeContents(e);const o=window.getSelection();o.removeAllRanges(),o.addRange(n);try{document.execCommand("copy"),s()}catch{}o.removeRange(n)}),n.classList.contains("highlight")?n.appendChild(t):n.parentNode.firstChild==n||(e.parentNode.parentNode.parentNode.parentNode.parentNode.nodeName=="TABLE"?e.parentNode.parentNode.parentNode.parentNode.parentNode.appendChild(t):e.parentNode.appendChild(t))})</script></body></html>
\ No newline at end of file
diff --git a/public/os/choosing-your-desktop-linux-distribution/index.html b/public/os/choosing-your-desktop-linux-distribution/index.html
new file mode 100644
index 0000000..e3bd30b
--- /dev/null
+++ b/public/os/choosing-your-desktop-linux-distribution/index.html
@@ -0,0 +1,11 @@
+<!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>Choosing Your Desktop Linux Distribution | PrivSec.dev</title><meta name=keywords content="operating system,security,linux"><meta name=description content="Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer."><meta name=author content="Tommy"><link rel=canonical href=https://privsec.dev/os/choosing-your-desktop-linux-distribution/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><script defer crossorigin=anonymous src=/assets/js/highlight.f413e19d0714851f6474e7ee9632408e58ac146fbdbe62747134bea2fa3415e0.js integrity="sha256-9BPhnQcUhR9kdOfuljJAjlisFG+9vmJ0cTS+ovo0FeA=" onload=hljs.initHighlightingOnLoad()></script>
+<link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="Choosing Your Desktop Linux Distribution"><meta property="og:description" content="Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer."><meta property="og:type" content="article"><meta property="og:url" content="https://privsec.dev/os/choosing-your-desktop-linux-distribution/"><meta property="article:section" content="os"><meta name=twitter:card content="summary"><meta name=twitter:title content="Choosing Your Desktop Linux Distribution"><meta name=twitter:description content="Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Operating Systems","item":"https://privsec.dev/os/"},{"@type":"ListItem","position":3,"name":"Choosing Your Desktop Linux Distribution","item":"https://privsec.dev/os/choosing-your-desktop-linux-distribution/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Choosing Your Desktop Linux Distribution","name":"Choosing Your Desktop Linux Distribution","description":"Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.\nRelease cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.\nFor frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer.","keywords":["operating system","security","linux"],"articleBody":"Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.\nRelease cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.\nFor frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer. Some security fixes do not receive a CVE (particularly less popular software) at all and therefore do not make it into the distribution with this patching model. As a result minor security fixes are sometimes held back until the next major release.\nHolding packages back and applying interim patches is generally not a good idea, as it diverges from the way the developer might have intended the software to work. Richard Brown has a presentation about this:\nTraditional and Atomic updates Traditionally, Linux distributions update by sequentially updating the desired packages. Traditional updates such as those used in Fedora, Arch Linux, and Debian based distributions can be less reliable if an error occurs while updating.\nAtomic updating distributions apply updates in full or not at all. Typically, transactional update systems are also atomic.\nA transactional update system creates a snapshot that is made before and after an update is applied. If an update fails at any time (perhaps due to a power failure), the update can be easily rolled back to a “last known good state.\"\nAdam Šamalík has a presentation with rpm-ostree in action:\nEven if you are worried about the stability of the system because of regularly updated packages (which you shouldn’t), it makes more sense to use a system which you can safely update and rollback instead of an outdated distribution partially made up of unreliable backport packages without an easy to actually roll back in case something goes wrong like Debian.\nArch-based distributions Acrh Linux has very up to date packages with minimal downstream patching. That being said, Arch based distributions are not recommended for those new to Linux, regardless of the distribution. Arch does not have an distribution update mechanism for the underlying software choices. As a result you have to stay aware with current trends and adopt technologies as they supersede older practices on your own.\nFor a secure system, you are also expected to have sufficient Linux knowledge to properly set up security for their system such as adopting a mandatory access control system, setting up kernel module blacklists, hardening boot parameters, manipulating sysctl parameters, and knowing what components they need such as Polkit.\nIf you are experienced with Linux and wish to use an Arch-based distribution, you should use Arch Linux proper, not any of its derivatives. Here are some examples of why that is the case:\nManjaro: This distribution holds packages back for 2 weeks to make sure that their own changes do not break, not to make sure that upstream is stable. When AUR packages are used, they are often built against the latest libraries from Arch’s repositories. Garuda: They use Chaotic-AUR which automatically and blindly compiles packages from the AUR. There is no verification process to make sure that the AUR packages don’t suffer from supply chain attacks. Kicksecure While you should not use an outdated distributions like Debian, if you decide to use it, it would be a good idea to convert it into Kicksecure. Kicksecure, in oversimplified terms, is a set of scripts, configurations, and packages that substantially reduce the attack surface of Debian. It covers a lot of privacy and hardening recommendations by default.\n“Security-focused” distributions There is often some confusion about “security-focused” distributions and “pentesting” distributions. A quick search for “the most secure Linux distribution” will often give results like Kali Linux, Black Arch and Parrot OS. These distributions are offensive penetration testing distributions that bundle tools for testing other systems. They don’t include any “extra security” or defensive mitigations intended for regular use.\nLinux-libre kernel and “Libre” distributions Do not the Linux-libre kernel, since it removes security mitigations and suppresses kernel warnings about vulnerable microcode for ideological reasons.\nIf you want to use one of these distributions for reasons other than ideology, you should make sure that they there is a way to easily obtain, install and update a proper kernel and missing firmware. For example, if you are looking to use GUIX, you should absolutely use something like the Nonguix repository and get all of the fixes as mentioned above.\nWayland You should a desktop environment that supports the Wayland display protocol as it developed with security in mind. Its predecessor, X11, does not support GUI isolation, allowing all windows to record screen, log and inject inputs in other windows, making any attempt at sandboxing futile. While there are options to do nested X11 such as Xpra or Xephyr, they often come with negative performance consequences and are not convenient to set up and are not preferable over Wayland.\nFortunately, common environments such as GNOME, KDE, and the window manager Sway have support for Wayland. Some distributions like Fedora and Tumbleweed use it by default, and some others may do so in the future as X11 is in hard maintenance mode. If you’re using one of those environments it is as easy as selecting the “Wayland” session at the desktop display manager (GDM, SDDM).\nTry not to use desktop environments or window managers that do not have Wayland support such as Cinnamon (default on Linux Mint), Pantheon (default on Elementary OS), MATE, Xfce, and i3.\n","wordCount":"944","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Tommy"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/os/choosing-your-desktop-linux-distribution/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/os/>Operating Systems</a></div><h1 class=post-title>Choosing Your Desktop Linux Distribution</h1><div class=post-meta>5 min&nbsp;·&nbsp;944 words&nbsp;·&nbsp;Tommy&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/blob/main/content/os/Choosing%20Your%20Desktop%20Linux%20Distribution.md rel="noopener noreferrer" target=_blank>Suggest Changes</a></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#release-cycle aria-label="Release cycle">Release cycle</a></li><li><a href=#traditional-and-atomic-updates aria-label="Traditional and Atomic updates">Traditional and Atomic updates</a></li><li><a href=#arch-based-distributions aria-label="Arch-based distributions">Arch-based distributions</a></li><li><a href=#kicksecure aria-label=Kicksecure>Kicksecure</a></li><li><a href=#security-focused-distributions aria-label="“Security-focused” distributions">“Security-focused” distributions</a></li><li><a href=#linux-libre-kernel-and-libre-distributions aria-label="Linux-libre kernel and “Libre” distributions">Linux-libre kernel and “Libre” distributions</a></li><li><a href=#wayland aria-label=Wayland>Wayland</a></li></ul></div></details></div><div class=post-content><p>Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.</p><h3 id=release-cycle>Release cycle<a hidden class=anchor aria-hidden=true href=#release-cycle>#</a></h3><p>You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.</p><p>For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such <a href=https://www.debian.org/security/faq#handling>example</a>) rather than bump the software to the “next version” released by the upstream developer. Some security fixes <a href=https://arxiv.org/abs/2105.14565>do not</a> receive a <a href=https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures>CVE</a> (particularly less popular software) at all and therefore do not make it into the distribution with this patching model. As a result minor security fixes are sometimes held back until the next major release.</p><p>Holding packages back and applying interim patches is generally not a good idea, as it diverges from the way the developer might have intended the software to work. <a href=https://rootco.de/aboutme/>Richard Brown</a> has a presentation about this:</p><div style=position:relative;padding-bottom:56.25%;height:0;overflow:hidden><iframe src=https://www.youtube-nocookie.com/embed/i8c0mg_mS7U style=position:absolute;top:0;left:0;width:100%;height:100%;border:0 allowfullscreen title="YouTube Video"></iframe></div><h3 id=traditional-and-atomic-updates>Traditional and Atomic updates<a hidden class=anchor aria-hidden=true href=#traditional-and-atomic-updates>#</a></h3><p>Traditionally, Linux distributions update by sequentially updating the desired packages. Traditional updates such as those used in Fedora, Arch Linux, and Debian based distributions can be less reliable if an error occurs while updating.</p><p>Atomic updating distributions apply updates in full or not at all. Typically, transactional update systems are also atomic.</p><p>A transactional update system creates a snapshot that is made before and after an update is applied. If an update fails at any time (perhaps due to a power failure), the update can be easily rolled back to a “last known good state."</p><p><a href=https://twitter.com/adsamalik>Adam Šamalík</a> has a presentation with <code>rpm-ostree</code> in action:</p><div style=position:relative;padding-bottom:56.25%;height:0;overflow:hidden><iframe src=https://www.youtube-nocookie.com/embed/-hpV5l-gJnQ style=position:absolute;top:0;left:0;width:100%;height:100%;border:0 allowfullscreen title="YouTube Video"></iframe></div><p>Even if you are worried about the stability of the system because of regularly updated packages (which you shouldn&rsquo;t), it makes more sense to use a system which you can safely update and rollback instead of an outdated distribution partially made up of unreliable backport packages without an easy to actually roll back in case something goes wrong like Debian.</p><h3 id=arch-based-distributions>Arch-based distributions<a hidden class=anchor aria-hidden=true href=#arch-based-distributions>#</a></h3><p>Acrh Linux has very up to date packages with minimal downstream patching. That being said, Arch based distributions are not recommended for those new to Linux, regardless of the distribution. Arch does not have an distribution update mechanism for the underlying software choices. As a result you have to stay aware with current trends and adopt technologies as they supersede older practices on your own.</p><p>For a secure system, you are also expected to have sufficient Linux knowledge to properly set up security for their system such as adopting a <a href=https://en.wikipedia.org/wiki/Mandatory_access_control>mandatory access control</a> system, setting up <a href=https://en.wikipedia.org/wiki/Loadable_kernel_module#Security>kernel module</a> blacklists, hardening boot parameters, manipulating <a href=https://en.wikipedia.org/wiki/Sysctl>sysctl</a> parameters, and knowing what components they need such as <a href=https://en.wikipedia.org/wiki/Polkit>Polkit</a>.</p><p>If you are experienced with Linux and wish to use an Arch-based distribution, you should use Arch Linux proper, not any of its derivatives. Here are some examples of why that is the case:</p><ul><li><strong>Manjaro</strong>: This distribution holds packages back for 2 weeks to make sure that their own changes do not break, not to make sure that upstream is stable. When AUR packages are used, they are often built against the latest <a href=https://en.wikipedia.org/wiki/Library_(computing)>libraries</a> from Arch’s repositories.</li><li><strong>Garuda</strong>: They use <a href=https://aur.chaotic.cx/>Chaotic-AUR</a> which automatically and blindly compiles packages from the AUR. There is no verification process to make sure that the AUR packages don’t suffer from supply chain attacks.</li></ul><h3 id=kicksecure>Kicksecure<a hidden class=anchor aria-hidden=true href=#kicksecure>#</a></h3><p>While you should not use an outdated distributions like Debian, if you decide to use it, it would be a good idea to <a href=https://www.kicksecure.com/wiki/Debian>convert</a> it into <a href=https://www.kicksecure.com/>Kicksecure</a>. Kicksecure, in oversimplified terms, is a set of scripts, configurations, and packages that substantially reduce the attack surface of Debian. It covers a lot of privacy and hardening recommendations by default.</p><h3 id=security-focused-distributions>“Security-focused” distributions<a hidden class=anchor aria-hidden=true href=#security-focused-distributions>#</a></h3><p>There is often some confusion about “security-focused” distributions and “pentesting” distributions. A quick search for “the most secure Linux distribution” will often give results like Kali Linux, Black Arch and Parrot OS. These distributions are offensive penetration testing distributions that bundle tools for testing other systems. They don’t include any “extra security” or defensive mitigations intended for regular use.</p><h3 id=linux-libre-kernel-and-libre-distributions>Linux-libre kernel and “Libre” distributions<a hidden class=anchor aria-hidden=true href=#linux-libre-kernel-and-libre-distributions>#</a></h3><p><strong>Do not</strong> the Linux-libre kernel, since it <a href="https://www.phoronix.com/scan.php?page=news_item&px=GNU-Linux-Libre-5.7-Released">removes security mitigations</a> and <a href="https://news.ycombinator.com/item?id=29674846">suppresses kernel warnings</a> about vulnerable microcode for ideological reasons.</p><p>If you want to use one of these distributions for reasons other than ideology, you should make sure that they there is a way to easily obtain, install and update a proper kernel and missing firmware. For example, if you are looking to use <a href=https://guix.gnu.org/en/download/>GUIX</a>, you should absolutely use something like the <a href=https://gitlab.com/nonguix/nonguix>Nonguix</a> repository and get all of the fixes as mentioned above.</p><h3 id=wayland>Wayland<a hidden class=anchor aria-hidden=true href=#wayland>#</a></h3><p>You should a desktop environment that supports the <a href=https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)>Wayland</a> display protocol as it developed with security <a href=https://lwn.net/Articles/589147/>in mind</a>. Its predecessor, <a href=https://en.wikipedia.org/wiki/X_Window_System>X11</a>, does not support GUI isolation, allowing all windows to <a href=https://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html>record screen, log and inject inputs in other windows</a>, making any attempt at sandboxing futile. While there are options to do nested X11 such as <a href=https://en.wikipedia.org/wiki/Xpra>Xpra</a> or <a href=https://en.wikipedia.org/wiki/Xephyr>Xephyr</a>, they often come with negative performance consequences and are not convenient to set up and are not preferable over Wayland.</p><p>Fortunately, common environments such as <a href=https://www.gnome.org>GNOME</a>, <a href=https://kde.org>KDE</a>, and the window manager <a href=https://swaywm.org>Sway</a> have support for Wayland. Some distributions like Fedora and Tumbleweed use it by default, and some others may do so in the future as X11 is in <a href="https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Maintenance-Mode-Quickly">hard maintenance mode</a>. If you’re using one of those environments it is as easy as selecting the “Wayland” session at the desktop display manager (<a href=https://en.wikipedia.org/wiki/GNOME_Display_Manager>GDM</a>, <a href=https://en.wikipedia.org/wiki/Simple_Desktop_Display_Manager>SDDM</a>).</p><p>Try <strong>not</strong> to use desktop environments or window managers that do not have Wayland support such as Cinnamon (default on Linux Mint), Pantheon (default on Elementary OS), MATE, Xfce, and i3.</p></div><footer class=post-footer><ul class=post-tags><li><a href=https://privsec.dev/tags/operating-system/>operating system</a></li><li><a href=https://privsec.dev/tags/security/>security</a></li><li><a href=https://privsec.dev/tags/linux/>linux</a></li></ul><nav class=paginav><a class=next href=https://privsec.dev/os/docker-and-oci-hardening/><span class=title>Next »</span><br><span>Docker and OCI Hardening</span></a></nav></footer></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+<span>Powered by
+<a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
+        <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script><script>document.querySelectorAll("pre > code").forEach(e=>{const n=e.parentNode.parentNode,t=document.createElement("button");t.classList.add("copy-code"),t.innerHTML="copy";function s(){t.innerHTML="copied!",setTimeout(()=>{t.innerHTML="copy"},2e3)}t.addEventListener("click",t=>{if("clipboard"in navigator){navigator.clipboard.writeText(e.textContent),s();return}const n=document.createRange();n.selectNodeContents(e);const o=window.getSelection();o.removeAllRanges(),o.addRange(n);try{document.execCommand("copy"),s()}catch{}o.removeRange(n)}),n.classList.contains("highlight")?n.appendChild(t):n.parentNode.firstChild==n||(e.parentNode.parentNode.parentNode.parentNode.parentNode.nodeName=="TABLE"?e.parentNode.parentNode.parentNode.parentNode.parentNode.appendChild(t):e.parentNode.appendChild(t))})</script></body></html>
\ No newline at end of file
diff --git a/public/os/docker-and-oci-hardening/index.html b/public/os/docker-and-oci-hardening/index.html
index db0fabc..50f0506 100644
--- a/public/os/docker-and-oci-hardening/index.html
+++ b/public/os/docker-and-oci-hardening/index.html
@@ -8,7 +8,7 @@ Whether we like them or not, containers are here to stay. Their expressiveness a
 Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries."><meta property="og:type" content="article"><meta property="og:url" content="https://privsec.dev/os/docker-and-oci-hardening/"><meta property="article:section" content="os"><meta name=twitter:card content="summary"><meta name=twitter:title content="Docker and OCI Hardening"><meta name=twitter:description content="Containers aren&rsquo;t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:
 - Hey, your software doesn&rsquo;t work&mldr;
 - Sorry, it works on my computer! Can&rsquo;t help you.
-Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Operating Systems","item":"https://privsec.dev/os/"},{"@type":"ListItem","position":3,"name":"Docker and OCI Hardening","item":"https://privsec.dev/os/docker-and-oci-hardening/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Docker and OCI Hardening","name":"Docker and OCI Hardening","description":"Containers aren\u0026rsquo;t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:\n- Hey, your software doesn\u0026rsquo;t work\u0026hellip;\n- Sorry, it works on my computer! Can\u0026rsquo;t help you.\nWhether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries.","keywords":["operating systems","linux","container","security"],"articleBody":"Containers aren’t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:\n- Hey, your software doesn’t work…\n- Sorry, it works on my computer! Can’t help you.\nWhether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries. The developer can therefore provide a known-good environment where it is expected that their software “just works”. That is particularly useful for development to eliminate environment-related issues, and that is often used in production as well.\nContainers are often perceived as a great tool for isolation, that is, they can provide an isolated workspace that won’t pollute your host OS - all that without the overhead of virtual machines. Security-wise: containers, as we know them on Linux, are glorified namespaces at their core. Containers usually share the same kernel with the host, and namespaces is the kernel feature for separating kernel resources across containers (IDs, networks, filesystems, IPC, etc.). Containers also leverage the features of cgroups to separate system resources (CPU, memory, etc.), and security features such as seccomp to restrict syscalls, or MACs (AppArmor, SELinux).\nAt first, it seems that containers may not provide the same isolation boundary as virtual machines. That’s fine, they were not designed to. But they can’t be simplified to a simple chroot either. We’ll see that a “container” can mean a lot of things, and their definition may vary a lot depending on the implementation: as such, containers are mostly defined by their semantics.\nDocker is dead, long live Docker… and OCI! When people think of containers, a large group of them may think of Docker. While Docker played a big role in the popularity of containers a few years ago, it didn’t introduce the technology: on Linux, LXC did (Linux Containers). In fact, Docker in its early days was a high-level wrapper for LXC which already combined the power of namespaces and cgroups. Docker then replaced LXC with libcontainer which does more or less the same, plus extra features.\nThen, what happened? Open Container Initiative (OCI). That is the current standard that defines the container ecosystem. That means that whether you’re using Docker, Podman, or Kubernetes, you’re in fact running OCI-compliant tools. That is a good thing, as it saves a lot of interoperability headaches.\nDocker is no longer the monolithic platform it once was. libcontainer was absorbed by runc, the reference OCI runtime. The high-level components of Docker split into different parts related to the upstream Moby project (Docker is the “assembled product” of the “Moby components”). When we refer to Docker, we refer in fact at this powerful high-level API that manages OCI containers. By design, Docker is a daemon that communicates with containerd, a lower-level layer, which in turn communicates with the OCI runtime. That also means that you could very well skip Docker altogether and use containerd or even runc directly.\nDocker client \u003c=\u003e Docker daemon \u003c=\u003e containerd \u003c=\u003e containerd-shim \u003c=\u003e runc Podman is an alternative to Docker developed by RedHat, that also intends to be a drop-in replacement for Docker. It doesn’t work with a daemon, and can work rootless by design (Docker has support for rootless too, but that is not without caveats). I would largely recommend Podman over Docker for someone who wants a simple tool to run containers and test code on their machine.\nKubernetes (also known as K8S) is the container platform made by Google. It is designed with scaling in mind, and is about running containers across a cluster whereas Docker focuses on packaging containers on a single node. Docker Swarm is the direct alternative to that, but it has never really took off due to the popularity of K8S.\nFor the rest of this article, we will use Docker as the reference for our examples, along with the Compose specification format. Most of these examples can be adapted to other platforms without issues.\nThe nightmare of dependencies Containers are made from images, and images are typically built from a Dockerfile. Images can be built and distributed through OCI registries: Docker Hub, Google Container Registry, GitHub Container Registry, and so on. You can also set up your own private registry as well, but the reality is that people often pull images from these public registries.\nImages, immutability and versioning Images are what make containers, well, containers. Containers made from the same image should behave similary on different machines. Images can have tags, which are useful for software versioning. The usage of generic tags such as latest is often discouraged because it defeats the purpose of the expected behavior of the container. Tags are not necessarily immutable by design, and they shouldn’t be (more on that below). Digest, however, is the attribute of an immutable image, and is often generated with the SHA-256 algorithm.\ndocker.io/library/golang:1.17.1@sha256:232a180dbcbcfa7250917507f3827d88a9ae89bb1cdd8fe3ac4db7b764ebb25 ^ ^ ^ ^ | | | | Registry Image Tag Digest (immutable) Now onto why tags shouldn’t be immutable: as written above, containers bring us an abstraction over the OS dependencies that are used by the packaged software. That is nice indeed, but this shouldn’t lure us into believing that we can forget security updates. The fact is, there is still a whole OS to care about, and we can’t just think of the container as a simple package tool for software.\nFor these reasons, good practices were established:\nAn image should be as minimal as possible (Alpine Linux, or scratch/distroless). An image, with a given tag, should be regularly built, without cache to ensure all layers are freshly built. An image should be rebuilt when the images it’s based on are updated. A minimal base system Alpine Linux is often the choice for official images for the first reason. This is not a typical Linux distribution as it uses musl as its C library, but it works quite well. Actually, I’m quite fond of Alpine Linux and apk (its package manager). If a supervision suite is needed, I’d look into s6. If you need a glibc distribution, Debian provides slim variants for lightweight base images. We can do even better than using Alpine by using distroless images, allowing us to have state-of-the-art application containers.\n“Distroless” is a fancy name referring to an image with a minimal set of dependencies, from none (for fully static binaries) to some common libraries (typically the C library). Google maintains distroless images you can use as a base for your own images. If you were wondering, the difference with scratch (empty starting point) is that distroless images contain common dependencies that “almost-statically compiled” binaries may need, such as ca-certificates.\nHowever, distroless images are not suited for every application. In my experience though, distroless is an excellent option with pure Go binaries. Going with minimal images drastically reduces the available attack surface in the container. For example, here’s a multi-stage Dockerfile resulting in a minimal non-root image for a simple Go project:\nFROM golang:alpine as build WORKDIR /app COPY . . RUN CGO_ENABLED=0 go mod -o /my_app cmd/my_app FROM gcr.io/distroless/static COPY --from=build /my_app / USER nobody ENTRYPOINT [\"/my_app\"] The main drawback of using minimal images is the lack of tools that help with debugging, which also constitute the very attack surface we’re trying to get rid of. The trade-off is probably not worth the hassle for development-focused containers, and if you’re running such images in production, you have to be confident enough to operate with them. Note that the gcr.io/distroless images have a :debug tag to help in that regard.\nKeeping images up-to-date The two other points are highly problematic, because most software vendors just publish an image on release, and forget about it. You should take it up to them if you’re running images that are versioned but not regularly updated. I’d say running scheduled builds once a week is the bare minimum to make sure dependencies stay up-to-date. Alpine Linux is a better choice than most other “stable” distributions because it usually has more recent packages.\nStable distributions often rely on backporting security fixes from CVEs, which is known to be a flawed approach to security since CVEs aren’t always assigned or even taken care of. Alpine has more recent packages, and it has versioning, so it’s once again a particulary good choice as long as musl doesn’t cause issues.\nIs it really a security nightmare? When people say Docker is a security nightmare because of that, that’s a fair point. On a traditional system, you could upgrade your whole system with a single command or two. With Docker, you’ll have to recreate several containers… if the images were kept up-to-date in the first place. Recreating itself is not a big deal actually: hot upgrades of binaries and libraries often require the services that use them to restart, otherwise they could still use an old (and vulnerable) version of them in memory. But yeah, the fact is most people are running outdated containers, and more often than not, they don’t have the choice if they rely on third-party images.\nTrivy is an excellent tool to scan images for a subset of known vulnerabilities an image might have. You should play with it and see for yourself how outdated many publicly available images are.\nSupply-chain attacks As with any code downloaded from a software vendor, OCI images are not exempt from supply-chain attacks. The good practice is quite simple: rely on official images, and ideally build and maintain your own images. One should definitely not automatically trust random third-party images they can find on Docker Hub. Half of these images, if not more, contain vulnerabilities, and I bet a good portion of them contains malwares such as miners or worse.\nAs an image maintainer, you can sign your images to improve the authenticity assurance. Most official images make use of Docker Content Trust, which works with a OCI registry attached to a Notary server. With the Docker toolset, setting the environment variable DOCKER_CONTENT_TRUST=1 enforces signature verification (a signature is only good if it’s checked in the first place). The SigStore initiative is developing cosign, an alternative that doesn’t require a Notary server because it works with features already provided by the registry such as tags. Kubernetes users may be interested in Connaisseur to ensure all signatures have been validated.\nLeave my root alone! Attack surface Traditionally, Docker runs as a daemon owned by root. That also means that root in the container is actually the root on the host and may be a few commands away from compromising the host. More generally, the attacker has to exploit the available attack surface to escape the container. There is a huge attack surface, actually: the Linux kernel. Someone wise once said:\nThe kernel can effectively be thought of as the largest, most vulnerable setuid root binary on the system.\nThat applies particulary to traditional containers which weren’t designed to provide a robust level of isolation. A recent example was CVE-2022-0492: the attacker could abuse root in the container to exploit cgroups v1, and compromise the host. Of course defense-in-depth measures would have prevented that, and we’ll mention them. But fundamentally, container escapes are possible by design.\nBreaking out via the OCI runtime runc is also possible, although CVE-2019-5736 was a particularly nasty bug. The attacker had to gain access to root in the container first in order to access /proc/[runc-pid]/exe, which indicates them where to overwrite the runc binary.\nGood practices have been therefore established:\nAvoid using root in the container, plain and simple. Keep the host kernel, Docker and the OCI runtime updated. Consider the usage of user namespaces. By the way, it goes without saying that any user who has access to the Docker daemon should be considered as privileged as root. Mounting the Docker socket (/var/run/docker.sock) in a container makes it highly privileged, and so it should be avoided. The socket should only be owned by root, and if that doesn’t work with your environment, use Docker rootless or Podman.\nAvoiding root root can be avoided in different ways in the final container:\nImage creation time: setting the USER instruction in the Dockerfile. Container creation time: via the tools available (user: in the Compose file). Container runtime: degrading privileges with entrypoints scripts (gosu UID:GID). Well-made images with security in mind will have a USER instruction. In my experience, most people will run images blindly, so it’s good harm reduction. Setting the user manually works in some images that aren’t designed without root in mind, and it’s also great to mitigate some scenarii where the image is controlled by an attacker. You also won’t have surprises when mounting volumes, so I highly recommend setting the user explicitly and make sure volume permissions are correct once.\nSome images allow users to define their own user with UID/GID environment variables, with an entrypoint script that runs as root and takes care of the volume permissions before dropping privileges. While technically fine, it is still attack surface, and it requires the SETUID/SETGID capabilities to be available in the container.\nUser namespaces: sandbox or paradox? As mentioned just above, user namespaces are a solution to ensure root in the container is not root on the host. Docker supports user namespaces, for instance you could set the default mapping in /etc/docker/daemon.json:\n\"userns-remap\": \"default\" whoami \u0026\u0026 sleep 60 in the container will return root, but ps -fC sleep on the host will show us the PID of another user. That is nice, but it has limitations and therefore shouldn’t be considered as a real sandbox. In fact, the paradox is that user namespaces are attack surface (and vulnerabilities are still being found years later), and it’s common wisdom to restrict them to privileged users (kernel.unprivileged_userns_clone=0). That is fine for Docker with its traditional root daemon, but Podman expects you to let unprivileged users interact with user namespaces (so essentially privileged code).\nEnabling userns-remap in Docker shouldn’t be a substitute for running unprivileged application containers (where applicable). User namespaces are mostly useful if you intend to run full-fledged OS containers which need root in order to function, but that is out of the scope of the container technologies mentioned in this article; for them, I’d argue exposing such a vulnerable attack surface from the host kernel for dubious sandboxing benefits isn’t an interesting trade-off to make.\nThe no_new_privs bit After ensuring root isn’t used in your containers, you should look into setting the no_new_privs bit. This Linux feature restricts syscalls such as execve() from granting privileges, which is what you want to restrict in-container privilege escalation. This flag can be set for a given container in a Compose file:\nsecurity_opt: - no-new-privileges: true Gaining privileges in the container will be much harder that way.\nCapabilities Furthermore, we should mention capabilities: root powers are divided into distinct units by the Linux kernel, called capabilities. Each granted capability also grants privilege and therefore access to a significant amount of attack surface. Security researcher Brad Spengler enumerates 19 important capabilities. Docker restricts certain capabilities by default, but some of the most important ones are still available to a container by default.\nYou should consider the following rule of thumb:\nDrop all capabilities by default. Allow only the ones you really need to. If you already run your containers unprivileged without root, your container will very likely work fine with all capabilities dropped. That can be done in a Compose file:\ncap_drop: - ALL #cap_add: # - CHOWN # - DAC_READ_SEARCH # - SETUID # - SETGID Never use the --privileged option unless you really need to: a privileged container is given access to almost all capabilities, kernel features and devices.\nOther security features MACs and seccomp are robust tools that may vastly improve container security.\nMandatory Access Control MAC stand for Mandatory Access Control: traditionnally a Linux Security Module that will enforce a policy to restrict the userspace. Examples are AppArmor and SELinux: the former being more easy-to-use, the later being more fine-grained. Both are strong tools that can help… Yet, their sole presence does not mean they’re really effective. A robust policy starts from a deny all policy, and only allows the necessary resources to be accessed.\nseccomp seccomp (short for secure computing mode) on the other hand is a much simpler and complementary tool, and there is no reason not to use it. What it does is restricting a process to a set of system calls, thus drastically reducing the attack surface available.\nDocker provides default profiles for AppArmor and seccomp, and they’re enabled by default for newly created containers unless the unconfined option is explicitly passed. Note: Kubernetes doesn’t enable the default seccomp profile by default, so you should probably try it.\nThese profiles are a great start, but you should do much more if you take security seriously, because they were made to not break compatibility with a large range of images. The default seccomp profile only disables around 44 syscalls, which are mostly not very common and/or obsoleted. Of course, the best profile you can get is supposed to be written for a given program. It also doesn’t make sense to insist on the permissiveness of the default profiles, and a lof of work has gone into hardening containers.\ncgroups Use cgroups to restrict access to hardware and system resources. You likely don’t want a guest container to monopolize the host resources. You also don’t want to be vulnerable to stupid fork bomb attacks. In a Compose file, consider setting these limits:\nmem_limit: 4g cpus: 4 pids_limit: 256 More runtime options can be found in the official documentation. All of them should have a Compose spec equivalent.\nThe --cgroup-parent option should be avoided as it uses the host cgroup and not the one configured from Docker (or else), which is the default.\nRead-only filesystem It is good practice to treat the image as some refer to as the “golden image”.\nIn other words, you’ll run containers in read-only mode, with an immutable filesystem inherited from the image. Only the mounted volumes will be read/write accessible, and those should ideally be mounted with the noexec, nosuid and nodev options for extra security. If read/write access isn’t needed, mount these volumes as read-only too.\nHowever, the image may not be perfect and still require read/write access to some parts of the filesystem, likely directories such as /tmp, /run or /var. You can make a tmpfs for those (a temporary filesystem in the container attributed memory), because they’re not persistent data anyway.\nIn a Compose file, that would look like the following settings:\nread_only: true tmpfs: - /tmp:size=10M,mode=0770,uid=1000,gid=1000,noexec,nosuid,nodev That is quite verbose indeed, but that’s to show you the different options for a tmpfs mount. You want to restrict them in size and permissions ideally.\nNetwork isolation By default, all Docker containers will use the default network bridge. They will see and be able to communicate with each other. Each container should have its own user-defined bridge network, and each connection between containers should have an internal network. If you intend to run a reverse proxy in front of several containers, you should make a dedicated network for each container you want to expose to the reverse proxy.\nThe --network host option also shouldn’t be used for obvious reasons since the container would share the same network as the host, providing no isolation at all.\nAlternative runtimes (gVisor) runc is the reference OCI runtime, but that means other runtimes can exist as well as long as they’re compliant with the OCI standard. These runtimes can be interchanged quite seamlessly. There’s a few alternatives, such as crun or youki, respectively implemented in C and Rust (runc is a Go implementation). However, there is one particular runtime that does a lot more for security: runsc, provided by the gVisor project by the folks at Google.\nContainers are not a sandbox, and while we can improve their security, they will fundamentally share a common attack surface with the host. Virtual machines are a solution to that problem, but you might prefer container semantics and ecosystem. gVisor can be perceived as an attempt to get the “best of both worlds”: containers that are easy to manage while providing a native isolation boundary. gVisor did just that by implementing two things:\nSentry: an application kernel in Go, a language known to be memory-safe. It implements the Linux logic in userspace such as various system calls. Gofer: a host process which communicates with Sentry and the host filesystem, since Sentry is restricted in that aspect. A platform like ptrace or KVM is used to intercept system calls and redirect them from the application to Sentry, which is running in the userspace. This has some costs: there is a higher per-syscall overhead, and compatibility is reduced since not all syscalls are implemented. On top of that, gVisor employs security mechanisms we’ve glanced over above, such as a very restrictive seccomp profile between Sentry and the host kernel, the no_new_privs bit, and isolated namespaces from the host.\nThe security model of gVisor is comparable to what you would expect from a virtual machine. It is also very easy to install and use. The path to runsc along with its different configuration flags (runsc flags) should be added to /etc/docker/daemon.json:\n\"runtimes\": { \"runsc-ptrace\": { \"path\": \"/usr/local/bin/runsc\", \"runtimeArgs\": [ \"--platform=ptrace\" ] }, \"runsc-kvm\": { \"path\": \"/usr/local/bin/runsc\", \"runtimeArgs\": [ \"--platform=kvm\" ] } } runsc needs to start with root to set up some mitigations, including the use of its own network stack separated from the host. The sandbox itself drops privileges to nobody as soon as possible. You can still use runsc rootless if you want (which should be needed for Podman):\n./runsc --rootless do uname -a *** Warning: sandbox network isn't supported with --rootless, switching to host *** Linux 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux Linux 4.4.0 is shown because that is the version of the Linux API that Sentry tries to mimic. As you’ve probably guessed, you’re not really using Linux 4.4.0, but the application kernel that behaves like it. By the way, gVisor is of course compatible with cgroups.\nConclusion: what’s a container after all? Like I wrote above, a container is mostly defined by its semantics and ecosystem. Containers shouldn’t be solely defined by the OCI reference runtime implementation, as we’ve seen with gVisor that provides an entirely different security model.\nStill not convinced? What if I told you a container can leverage the same technologies as a virtual machine? That is exactly what Kata Containers does by using a VMM like QEMU-lite to provide containers that are in fact lightweight virtual machines, with their traditional resources and security model, compatibility with container semantics and toolset, and an optimized overhead. While not in the OCI ecosystem, Amazon achieves quite the same with Firecracker.\nIf you’re running untrusted workloads, I highly suggest you consider gVisor instead of a traditional container runtime. Your definition of “untrusted” may vary: for me, almost everything should be considered untrusted. That is how modern security works, and how mobile operating systems work. It’s quite simple, security should be simple, and gVisor simply offers native security.\nContainers are a popular, yet strange world. They revolutionized the way we make and deploy software, but one should not loose the sight of what they really are and aren’t. This hardening guide is non-exhaustive, but I hope it can make you aware of some aspects you’ve never thought of.\n","wordCount":"3925","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Wonderfall"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/os/docker-and-oci-hardening/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/os/>Operating Systems</a></div><h1 class=post-title>Docker and OCI Hardening</h1><div class=post-meta>19 min&nbsp;·&nbsp;3925 words&nbsp;·&nbsp;Wonderfall&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/content/os/Docker%20and%20OCI%20Hardening.md rel="noopener noreferrer" target=_blank>Suggest Changes</a>
+Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Operating Systems","item":"https://privsec.dev/os/"},{"@type":"ListItem","position":3,"name":"Docker and OCI Hardening","item":"https://privsec.dev/os/docker-and-oci-hardening/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Docker and OCI Hardening","name":"Docker and OCI Hardening","description":"Containers aren\u0026rsquo;t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:\n- Hey, your software doesn\u0026rsquo;t work\u0026hellip;\n- Sorry, it works on my computer! Can\u0026rsquo;t help you.\nWhether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries.","keywords":["operating systems","linux","container","security"],"articleBody":"Containers aren’t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:\n- Hey, your software doesn’t work…\n- Sorry, it works on my computer! Can’t help you.\nWhether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries. The developer can therefore provide a known-good environment where it is expected that their software “just works”. That is particularly useful for development to eliminate environment-related issues, and that is often used in production as well.\nContainers are often perceived as a great tool for isolation, that is, they can provide an isolated workspace that won’t pollute your host OS - all that without the overhead of virtual machines. Security-wise: containers, as we know them on Linux, are glorified namespaces at their core. Containers usually share the same kernel with the host, and namespaces is the kernel feature for separating kernel resources across containers (IDs, networks, filesystems, IPC, etc.). Containers also leverage the features of cgroups to separate system resources (CPU, memory, etc.), and security features such as seccomp to restrict syscalls, or MACs (AppArmor, SELinux).\nAt first, it seems that containers may not provide the same isolation boundary as virtual machines. That’s fine, they were not designed to. But they can’t be simplified to a simple chroot either. We’ll see that a “container” can mean a lot of things, and their definition may vary a lot depending on the implementation: as such, containers are mostly defined by their semantics.\nDocker is dead, long live Docker… and OCI! When people think of containers, a large group of them may think of Docker. While Docker played a big role in the popularity of containers a few years ago, it didn’t introduce the technology: on Linux, LXC did (Linux Containers). In fact, Docker in its early days was a high-level wrapper for LXC which already combined the power of namespaces and cgroups. Docker then replaced LXC with libcontainer which does more or less the same, plus extra features.\nThen, what happened? Open Container Initiative (OCI). That is the current standard that defines the container ecosystem. That means that whether you’re using Docker, Podman, or Kubernetes, you’re in fact running OCI-compliant tools. That is a good thing, as it saves a lot of interoperability headaches.\nDocker is no longer the monolithic platform it once was. libcontainer was absorbed by runc, the reference OCI runtime. The high-level components of Docker split into different parts related to the upstream Moby project (Docker is the “assembled product” of the “Moby components”). When we refer to Docker, we refer in fact at this powerful high-level API that manages OCI containers. By design, Docker is a daemon that communicates with containerd, a lower-level layer, which in turn communicates with the OCI runtime. That also means that you could very well skip Docker altogether and use containerd or even runc directly.\nDocker client \u003c=\u003e Docker daemon \u003c=\u003e containerd \u003c=\u003e containerd-shim \u003c=\u003e runc Podman is an alternative to Docker developed by RedHat, that also intends to be a drop-in replacement for Docker. It doesn’t work with a daemon, and can work rootless by design (Docker has support for rootless too, but that is not without caveats). I would largely recommend Podman over Docker for someone who wants a simple tool to run containers and test code on their machine.\nKubernetes (also known as K8S) is the container platform made by Google. It is designed with scaling in mind, and is about running containers across a cluster whereas Docker focuses on packaging containers on a single node. Docker Swarm is the direct alternative to that, but it has never really took off due to the popularity of K8S.\nFor the rest of this article, we will use Docker as the reference for our examples, along with the Compose specification format. Most of these examples can be adapted to other platforms without issues.\nThe nightmare of dependencies Containers are made from images, and images are typically built from a Dockerfile. Images can be built and distributed through OCI registries: Docker Hub, Google Container Registry, GitHub Container Registry, and so on. You can also set up your own private registry as well, but the reality is that people often pull images from these public registries.\nImages, immutability and versioning Images are what make containers, well, containers. Containers made from the same image should behave similary on different machines. Images can have tags, which are useful for software versioning. The usage of generic tags such as latest is often discouraged because it defeats the purpose of the expected behavior of the container. Tags are not necessarily immutable by design, and they shouldn’t be (more on that below). Digest, however, is the attribute of an immutable image, and is often generated with the SHA-256 algorithm.\ndocker.io/library/golang:1.17.1@sha256:232a180dbcbcfa7250917507f3827d88a9ae89bb1cdd8fe3ac4db7b764ebb25 ^ ^ ^ ^ | | | | Registry Image Tag Digest (immutable) Now onto why tags shouldn’t be immutable: as written above, containers bring us an abstraction over the OS dependencies that are used by the packaged software. That is nice indeed, but this shouldn’t lure us into believing that we can forget security updates. The fact is, there is still a whole OS to care about, and we can’t just think of the container as a simple package tool for software.\nFor these reasons, good practices were established:\nAn image should be as minimal as possible (Alpine Linux, or scratch/distroless). An image, with a given tag, should be regularly built, without cache to ensure all layers are freshly built. An image should be rebuilt when the images it’s based on are updated. A minimal base system Alpine Linux is often the choice for official images for the first reason. This is not a typical Linux distribution as it uses musl as its C library, but it works quite well. Actually, I’m quite fond of Alpine Linux and apk (its package manager). If a supervision suite is needed, I’d look into s6. If you need a glibc distribution, Debian provides slim variants for lightweight base images. We can do even better than using Alpine by using distroless images, allowing us to have state-of-the-art application containers.\n“Distroless” is a fancy name referring to an image with a minimal set of dependencies, from none (for fully static binaries) to some common libraries (typically the C library). Google maintains distroless images you can use as a base for your own images. If you were wondering, the difference with scratch (empty starting point) is that distroless images contain common dependencies that “almost-statically compiled” binaries may need, such as ca-certificates.\nHowever, distroless images are not suited for every application. In my experience though, distroless is an excellent option with pure Go binaries. Going with minimal images drastically reduces the available attack surface in the container. For example, here’s a multi-stage Dockerfile resulting in a minimal non-root image for a simple Go project:\nFROM golang:alpine as build WORKDIR /app COPY . . RUN CGO_ENABLED=0 go mod -o /my_app cmd/my_app FROM gcr.io/distroless/static COPY --from=build /my_app / USER nobody ENTRYPOINT [\"/my_app\"] The main drawback of using minimal images is the lack of tools that help with debugging, which also constitute the very attack surface we’re trying to get rid of. The trade-off is probably not worth the hassle for development-focused containers, and if you’re running such images in production, you have to be confident enough to operate with them. Note that the gcr.io/distroless images have a :debug tag to help in that regard.\nKeeping images up-to-date The two other points are highly problematic, because most software vendors just publish an image on release, and forget about it. You should take it up to them if you’re running images that are versioned but not regularly updated. I’d say running scheduled builds once a week is the bare minimum to make sure dependencies stay up-to-date. Alpine Linux is a better choice than most other “stable” distributions because it usually has more recent packages.\nStable distributions often rely on backporting security fixes from CVEs, which is known to be a flawed approach to security since CVEs aren’t always assigned or even taken care of. Alpine has more recent packages, and it has versioning, so it’s once again a particulary good choice as long as musl doesn’t cause issues.\nIs it really a security nightmare? When people say Docker is a security nightmare because of that, that’s a fair point. On a traditional system, you could upgrade your whole system with a single command or two. With Docker, you’ll have to recreate several containers… if the images were kept up-to-date in the first place. Recreating itself is not a big deal actually: hot upgrades of binaries and libraries often require the services that use them to restart, otherwise they could still use an old (and vulnerable) version of them in memory. But yeah, the fact is most people are running outdated containers, and more often than not, they don’t have the choice if they rely on third-party images.\nTrivy is an excellent tool to scan images for a subset of known vulnerabilities an image might have. You should play with it and see for yourself how outdated many publicly available images are.\nSupply-chain attacks As with any code downloaded from a software vendor, OCI images are not exempt from supply-chain attacks. The good practice is quite simple: rely on official images, and ideally build and maintain your own images. One should definitely not automatically trust random third-party images they can find on Docker Hub. Half of these images, if not more, contain vulnerabilities, and I bet a good portion of them contains malwares such as miners or worse.\nAs an image maintainer, you can sign your images to improve the authenticity assurance. Most official images make use of Docker Content Trust, which works with a OCI registry attached to a Notary server. With the Docker toolset, setting the environment variable DOCKER_CONTENT_TRUST=1 enforces signature verification (a signature is only good if it’s checked in the first place). The SigStore initiative is developing cosign, an alternative that doesn’t require a Notary server because it works with features already provided by the registry such as tags. Kubernetes users may be interested in Connaisseur to ensure all signatures have been validated.\nLeave my root alone! Attack surface Traditionally, Docker runs as a daemon owned by root. That also means that root in the container is actually the root on the host and may be a few commands away from compromising the host. More generally, the attacker has to exploit the available attack surface to escape the container. There is a huge attack surface, actually: the Linux kernel. Someone wise once said:\nThe kernel can effectively be thought of as the largest, most vulnerable setuid root binary on the system.\nThat applies particulary to traditional containers which weren’t designed to provide a robust level of isolation. A recent example was CVE-2022-0492: the attacker could abuse root in the container to exploit cgroups v1, and compromise the host. Of course defense-in-depth measures would have prevented that, and we’ll mention them. But fundamentally, container escapes are possible by design.\nBreaking out via the OCI runtime runc is also possible, although CVE-2019-5736 was a particularly nasty bug. The attacker had to gain access to root in the container first in order to access /proc/[runc-pid]/exe, which indicates them where to overwrite the runc binary.\nGood practices have been therefore established:\nAvoid using root in the container, plain and simple. Keep the host kernel, Docker and the OCI runtime updated. Consider the usage of user namespaces. By the way, it goes without saying that any user who has access to the Docker daemon should be considered as privileged as root. Mounting the Docker socket (/var/run/docker.sock) in a container makes it highly privileged, and so it should be avoided. The socket should only be owned by root, and if that doesn’t work with your environment, use Docker rootless or Podman.\nAvoiding root root can be avoided in different ways in the final container:\nImage creation time: setting the USER instruction in the Dockerfile. Container creation time: via the tools available (user: in the Compose file). Container runtime: degrading privileges with entrypoints scripts (gosu UID:GID). Well-made images with security in mind will have a USER instruction. In my experience, most people will run images blindly, so it’s good harm reduction. Setting the user manually works in some images that aren’t designed without root in mind, and it’s also great to mitigate some scenarii where the image is controlled by an attacker. You also won’t have surprises when mounting volumes, so I highly recommend setting the user explicitly and make sure volume permissions are correct once.\nSome images allow users to define their own user with UID/GID environment variables, with an entrypoint script that runs as root and takes care of the volume permissions before dropping privileges. While technically fine, it is still attack surface, and it requires the SETUID/SETGID capabilities to be available in the container.\nUser namespaces: sandbox or paradox? As mentioned just above, user namespaces are a solution to ensure root in the container is not root on the host. Docker supports user namespaces, for instance you could set the default mapping in /etc/docker/daemon.json:\n\"userns-remap\": \"default\" whoami \u0026\u0026 sleep 60 in the container will return root, but ps -fC sleep on the host will show us the PID of another user. That is nice, but it has limitations and therefore shouldn’t be considered as a real sandbox. In fact, the paradox is that user namespaces are attack surface (and vulnerabilities are still being found years later), and it’s common wisdom to restrict them to privileged users (kernel.unprivileged_userns_clone=0). That is fine for Docker with its traditional root daemon, but Podman expects you to let unprivileged users interact with user namespaces (so essentially privileged code).\nEnabling userns-remap in Docker shouldn’t be a substitute for running unprivileged application containers (where applicable). User namespaces are mostly useful if you intend to run full-fledged OS containers which need root in order to function, but that is out of the scope of the container technologies mentioned in this article; for them, I’d argue exposing such a vulnerable attack surface from the host kernel for dubious sandboxing benefits isn’t an interesting trade-off to make.\nThe no_new_privs bit After ensuring root isn’t used in your containers, you should look into setting the no_new_privs bit. This Linux feature restricts syscalls such as execve() from granting privileges, which is what you want to restrict in-container privilege escalation. This flag can be set for a given container in a Compose file:\nsecurity_opt: - no-new-privileges: true Gaining privileges in the container will be much harder that way.\nCapabilities Furthermore, we should mention capabilities: root powers are divided into distinct units by the Linux kernel, called capabilities. Each granted capability also grants privilege and therefore access to a significant amount of attack surface. Security researcher Brad Spengler enumerates 19 important capabilities. Docker restricts certain capabilities by default, but some of the most important ones are still available to a container by default.\nYou should consider the following rule of thumb:\nDrop all capabilities by default. Allow only the ones you really need to. If you already run your containers unprivileged without root, your container will very likely work fine with all capabilities dropped. That can be done in a Compose file:\ncap_drop: - ALL #cap_add: # - CHOWN # - DAC_READ_SEARCH # - SETUID # - SETGID Never use the --privileged option unless you really need to: a privileged container is given access to almost all capabilities, kernel features and devices.\nOther security features MACs and seccomp are robust tools that may vastly improve container security.\nMandatory Access Control MAC stand for Mandatory Access Control: traditionnally a Linux Security Module that will enforce a policy to restrict the userspace. Examples are AppArmor and SELinux: the former being more easy-to-use, the later being more fine-grained. Both are strong tools that can help… Yet, their sole presence does not mean they’re really effective. A robust policy starts from a deny all policy, and only allows the necessary resources to be accessed.\nseccomp seccomp (short for secure computing mode) on the other hand is a much simpler and complementary tool, and there is no reason not to use it. What it does is restricting a process to a set of system calls, thus drastically reducing the attack surface available.\nDocker provides default profiles for AppArmor and seccomp, and they’re enabled by default for newly created containers unless the unconfined option is explicitly passed. Note: Kubernetes doesn’t enable the default seccomp profile by default, so you should probably try it.\nThese profiles are a great start, but you should do much more if you take security seriously, because they were made to not break compatibility with a large range of images. The default seccomp profile only disables around 44 syscalls, which are mostly not very common and/or obsoleted. Of course, the best profile you can get is supposed to be written for a given program. It also doesn’t make sense to insist on the permissiveness of the default profiles, and a lof of work has gone into hardening containers.\ncgroups Use cgroups to restrict access to hardware and system resources. You likely don’t want a guest container to monopolize the host resources. You also don’t want to be vulnerable to stupid fork bomb attacks. In a Compose file, consider setting these limits:\nmem_limit: 4g cpus: 4 pids_limit: 256 More runtime options can be found in the official documentation. All of them should have a Compose spec equivalent.\nThe --cgroup-parent option should be avoided as it uses the host cgroup and not the one configured from Docker (or else), which is the default.\nRead-only filesystem It is good practice to treat the image as some refer to as the “golden image”.\nIn other words, you’ll run containers in read-only mode, with an immutable filesystem inherited from the image. Only the mounted volumes will be read/write accessible, and those should ideally be mounted with the noexec, nosuid and nodev options for extra security. If read/write access isn’t needed, mount these volumes as read-only too.\nHowever, the image may not be perfect and still require read/write access to some parts of the filesystem, likely directories such as /tmp, /run or /var. You can make a tmpfs for those (a temporary filesystem in the container attributed memory), because they’re not persistent data anyway.\nIn a Compose file, that would look like the following settings:\nread_only: true tmpfs: - /tmp:size=10M,mode=0770,uid=1000,gid=1000,noexec,nosuid,nodev That is quite verbose indeed, but that’s to show you the different options for a tmpfs mount. You want to restrict them in size and permissions ideally.\nNetwork isolation By default, all Docker containers will use the default network bridge. They will see and be able to communicate with each other. Each container should have its own user-defined bridge network, and each connection between containers should have an internal network. If you intend to run a reverse proxy in front of several containers, you should make a dedicated network for each container you want to expose to the reverse proxy.\nThe --network host option also shouldn’t be used for obvious reasons since the container would share the same network as the host, providing no isolation at all.\nAlternative runtimes (gVisor) runc is the reference OCI runtime, but that means other runtimes can exist as well as long as they’re compliant with the OCI standard. These runtimes can be interchanged quite seamlessly. There’s a few alternatives, such as crun or youki, respectively implemented in C and Rust (runc is a Go implementation). However, there is one particular runtime that does a lot more for security: runsc, provided by the gVisor project by the folks at Google.\nContainers are not a sandbox, and while we can improve their security, they will fundamentally share a common attack surface with the host. Virtual machines are a solution to that problem, but you might prefer container semantics and ecosystem. gVisor can be perceived as an attempt to get the “best of both worlds”: containers that are easy to manage while providing a native isolation boundary. gVisor did just that by implementing two things:\nSentry: an application kernel in Go, a language known to be memory-safe. It implements the Linux logic in userspace such as various system calls. Gofer: a host process which communicates with Sentry and the host filesystem, since Sentry is restricted in that aspect. A platform like ptrace or KVM is used to intercept system calls and redirect them from the application to Sentry, which is running in the userspace. This has some costs: there is a higher per-syscall overhead, and compatibility is reduced since not all syscalls are implemented. On top of that, gVisor employs security mechanisms we’ve glanced over above, such as a very restrictive seccomp profile between Sentry and the host kernel, the no_new_privs bit, and isolated namespaces from the host.\nThe security model of gVisor is comparable to what you would expect from a virtual machine. It is also very easy to install and use. The path to runsc along with its different configuration flags (runsc flags) should be added to /etc/docker/daemon.json:\n\"runtimes\": { \"runsc-ptrace\": { \"path\": \"/usr/local/bin/runsc\", \"runtimeArgs\": [ \"--platform=ptrace\" ] }, \"runsc-kvm\": { \"path\": \"/usr/local/bin/runsc\", \"runtimeArgs\": [ \"--platform=kvm\" ] } } runsc needs to start with root to set up some mitigations, including the use of its own network stack separated from the host. The sandbox itself drops privileges to nobody as soon as possible. You can still use runsc rootless if you want (which should be needed for Podman):\n./runsc --rootless do uname -a *** Warning: sandbox network isn't supported with --rootless, switching to host *** Linux 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux Linux 4.4.0 is shown because that is the version of the Linux API that Sentry tries to mimic. As you’ve probably guessed, you’re not really using Linux 4.4.0, but the application kernel that behaves like it. By the way, gVisor is of course compatible with cgroups.\nConclusion: what’s a container after all? Like I wrote above, a container is mostly defined by its semantics and ecosystem. Containers shouldn’t be solely defined by the OCI reference runtime implementation, as we’ve seen with gVisor that provides an entirely different security model.\nStill not convinced? What if I told you a container can leverage the same technologies as a virtual machine? That is exactly what Kata Containers does by using a VMM like QEMU-lite to provide containers that are in fact lightweight virtual machines, with their traditional resources and security model, compatibility with container semantics and toolset, and an optimized overhead. While not in the OCI ecosystem, Amazon achieves quite the same with Firecracker.\nIf you’re running untrusted workloads, I highly suggest you consider gVisor instead of a traditional container runtime. Your definition of “untrusted” may vary: for me, almost everything should be considered untrusted. That is how modern security works, and how mobile operating systems work. It’s quite simple, security should be simple, and gVisor simply offers native security.\nContainers are a popular, yet strange world. They revolutionized the way we make and deploy software, but one should not loose the sight of what they really are and aren’t. This hardening guide is non-exhaustive, but I hope it can make you aware of some aspects you’ve never thought of.\n","wordCount":"3925","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Wonderfall"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/os/docker-and-oci-hardening/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/os/>Operating Systems</a></div><h1 class=post-title>Docker and OCI Hardening</h1><div class=post-meta>19 min&nbsp;·&nbsp;3925 words&nbsp;·&nbsp;Wonderfall&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/blob/main/content/os/Docker%20and%20OCI%20Hardening.md rel="noopener noreferrer" target=_blank>Suggest Changes</a>
 &nbsp;|&nbsp;<span>Originally published at&nbsp;<a href=https://wonderfall.dev/docker-hardening/ title=https://wonderfall.dev/docker-hardening/ target=_blank rel="noopener noreferrer">wonderfall.dev</a></span></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#docker-is-dead-long-live-docker-and-oci aria-label="Docker is dead, long live Docker&amp;hellip; and OCI!">Docker is dead, long live Docker&mldr; and OCI!</a></li><li><a href=#the-nightmare-of-dependencies aria-label="The nightmare of dependencies">The nightmare of dependencies</a><ul><li><a href=#images-immutability-and-versioning aria-label="Images, immutability and versioning">Images, immutability and versioning</a></li><li><a href=#a-minimal-base-system aria-label="A minimal base system">A minimal base system</a></li><li><a href=#keeping-images-up-to-date aria-label="Keeping images up-to-date">Keeping images up-to-date</a></li><li><a href=#is-it-really-a-security-nightmare aria-label="Is it really a security nightmare?">Is it really a security nightmare?</a></li><li><a href=#supply-chain-attacks aria-label="Supply-chain attacks">Supply-chain attacks</a></li></ul></li><li><a href=#leave-my-root-alone aria-label="Leave my root alone!">Leave my root alone!</a><ul><li><a href=#attack-surface aria-label="Attack surface">Attack surface</a></li><li><a href=#avoiding-root aria-label="Avoiding root">Avoiding root</a></li><li><a href=#user-namespaces-sandbox-or-paradox aria-label="User namespaces: sandbox or paradox?">User namespaces: sandbox or paradox?</a></li><li><a href=#the-no_new_privs-bit aria-label="The no_new_privs bit">The no_new_privs bit</a></li><li><a href=#capabilities aria-label=Capabilities>Capabilities</a></li></ul></li><li><a href=#other-security-features aria-label="Other security features">Other security features</a><ul><li><a href=#mandatory-access-control aria-label="Mandatory Access Control">Mandatory Access Control</a></li><li><a href=#seccomp aria-label=seccomp>seccomp</a></li><li><a href=#cgroups aria-label=cgroups>cgroups</a></li><li><a href=#read-only-filesystem aria-label="Read-only filesystem">Read-only filesystem</a></li><li><a href=#network-isolation aria-label="Network isolation">Network isolation</a></li></ul></li><li><a href=#alternative-runtimes-gvisor aria-label="Alternative runtimes (gVisor)">Alternative runtimes (gVisor)</a></li><li><a href=#conclusion-whats-a-container-after-all aria-label="Conclusion: what&amp;rsquo;s a container after all?">Conclusion: what&rsquo;s a container after all?</a></li></ul></div></details></div><div class=post-content><p>Containers aren&rsquo;t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:</p><blockquote><p>- Hey, your software doesn&rsquo;t work&mldr;</p><p>- Sorry, it works on my computer! Can&rsquo;t help you.</p></blockquote><p>Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries. The developer can therefore provide a known-good environment where it is expected that their software &ldquo;just works&rdquo;. That is particularly useful for development to eliminate environment-related issues, and that is often used in production as well.</p><p>Containers are often perceived as a great tool for isolation, that is, they can provide an isolated workspace that won&rsquo;t pollute your host OS - all that without the overhead of virtual machines. Security-wise: containers, as we know them on Linux, are glorified namespaces at their core. Containers usually share the same kernel with the host, and <strong>namespaces</strong> is the kernel feature for separating kernel resources across containers (IDs, networks, filesystems, IPC, etc.). Containers also leverage the features of <strong>cgroups</strong> to separate system resources (CPU, memory, etc.), and security features such as seccomp to restrict syscalls, or MACs (AppArmor, SELinux).</p><p>At first, it seems that containers may not provide the same isolation boundary as virtual machines. That&rsquo;s fine, they were not designed to. But they can&rsquo;t be simplified to a simple <code>chroot</code> either. We&rsquo;ll see that a &ldquo;container&rdquo; can mean a lot of things, and their definition may vary a lot depending on the implementation: as such, containers are mostly defined by their semantics.</p><h2 id=docker-is-dead-long-live-docker-and-oci>Docker is dead, long live Docker&mldr; and OCI!<a hidden class=anchor aria-hidden=true href=#docker-is-dead-long-live-docker-and-oci>#</a></h2><p>When people think of containers, a large group of them may think of Docker. While Docker played a big role in the popularity of containers a few years ago, it didn&rsquo;t introduce the technology: on Linux, LXC did (<em>Linux Containers</em>). In fact, Docker in its early days was a high-level wrapper for LXC which already combined the power of namespaces and cgroups. Docker then replaced LXC with <code>libcontainer</code> which does more or less the same, plus extra features.</p><p>Then, what happened? <em>Open Container Initiative</em> (OCI). That is the current standard that defines the container ecosystem. That means that whether you&rsquo;re using Docker, Podman, or Kubernetes, you&rsquo;re in fact running OCI-compliant tools. That is a good thing, as it saves a lot of interoperability headaches.</p><p><strong>Docker</strong> is no longer the monolithic platform it once was. <code>libcontainer</code> was absorbed by <code>runc</code>, the reference OCI runtime. The high-level components of Docker split into different parts related to the upstream Moby project (Docker is the &ldquo;assembled product&rdquo; of the &ldquo;Moby components&rdquo;). When we refer to Docker, we refer in fact at this powerful high-level API that manages OCI containers. By design, Docker is a daemon that communicates with <code>containerd</code>, a lower-level layer, which in turn communicates with the OCI runtime. That also means that you could very well skip Docker altogether and use <code>containerd</code> or even <code>runc</code> directly.</p><pre tabindex=0><code>Docker client &lt;=&gt; Docker daemon &lt;=&gt; containerd &lt;=&gt; containerd-shim &lt;=&gt; runc
 </code></pre><p><strong>Podman</strong> is an alternative to Docker developed by RedHat, that also intends to be a drop-in replacement for Docker. It doesn&rsquo;t work with a daemon, and can work rootless by design (Docker has support for rootless too, but that is not without caveats). I would largely recommend Podman over Docker for someone who wants a simple tool to run containers and test code on their machine.</p><p><strong>Kubernetes</strong> (also known as K8S) is the container platform made by Google. It is designed with scaling in mind, and is about running containers across a cluster whereas Docker focuses on packaging containers on a single node. Docker Swarm is the direct alternative to that, but it has never really took off due to the popularity of K8S.</p><p>For the rest of this article, we will use Docker as the reference for our examples, along with the <a href=https://docs.docker.com/compose/compose-file/>Compose specification</a> format. Most of these examples can be adapted to other platforms without issues.</p><h2 id=the-nightmare-of-dependencies>The nightmare of dependencies<a hidden class=anchor aria-hidden=true href=#the-nightmare-of-dependencies>#</a></h2><p>Containers are made from images, and images are typically built from a Dockerfile. Images can be built and distributed through OCI registries: <a href=https://hub.docker.com/>Docker Hub</a>, <a href=https://cloud.google.com/container-registry>Google Container Registry</a>, <a href=https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry>GitHub Container Registry</a>, and so on. You can also set up your own private registry as well, but the reality is that people often pull images from these public registries.</p><h3 id=images-immutability-and-versioning>Images, immutability and versioning<a hidden class=anchor aria-hidden=true href=#images-immutability-and-versioning>#</a></h3><p>Images are what make containers, well, containers. Containers made from the same image should behave similary on different machines. Images can have <strong>tags</strong>, which are useful for software versioning. The usage of generic tags such as <code>latest</code> is often discouraged because it defeats the purpose of the expected behavior of the container. Tags are not necessarily immutable by design, and they shouldn&rsquo;t be (more on that below). <strong>Digest</strong>, however, is the attribute of an immutable image, and is often generated with the SHA-256 algorithm.</p><pre tabindex=0><code>docker.io/library/golang:1.17.1@sha256:232a180dbcbcfa7250917507f3827d88a9ae89bb1cdd8fe3ac4db7b764ebb25
          ^          ^       ^                                   ^ 
@@ -56,7 +56,8 @@ ENTRYPOINT [&#34;/my_app&#34;]
 </code></pre><p><code>runsc</code> needs to start with root to set up some mitigations, including the use of its own network stack separated from the host. The sandbox itself drops privileges to nobody as soon as possible. You can still use <code>runsc</code> rootless if you want (which should be needed for Podman):</p><pre tabindex=0><code>./runsc --rootless do uname -a
 *** Warning: sandbox network isn&#39;t supported with --rootless, switching to host ***
 Linux 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux
-</code></pre><p>Linux 4.4.0 is shown because that is the version of the Linux API that Sentry tries to mimic. As you&rsquo;ve probably guessed, you&rsquo;re not really using Linux 4.4.0, but the application kernel that behaves like it. By the way, gVisor is of course compatible with cgroups.</p><h2 id=conclusion-whats-a-container-after-all>Conclusion: what&rsquo;s a container after all?<a hidden class=anchor aria-hidden=true href=#conclusion-whats-a-container-after-all>#</a></h2><p>Like I wrote above, a container is mostly defined by its semantics and ecosystem. Containers shouldn&rsquo;t be solely defined by the OCI reference runtime implementation, as we&rsquo;ve seen with gVisor that provides an entirely different security model.</p><p>Still not convinced? What if I told you a container can leverage the same technologies as a virtual machine? That is exactly what <a href=https://katacontainers.io/>Kata Containers</a> does by using a VMM like QEMU-lite to provide containers that are in fact lightweight virtual machines, with their traditional resources and security model, compatibility with container semantics and toolset, and an optimized overhead. While not in the OCI ecosystem, Amazon achieves quite the same with <a href=https://firecracker-microvm.github.io/>Firecracker</a>.</p><p>If you&rsquo;re running untrusted workloads, I highly suggest you consider gVisor instead of a traditional container runtime. Your definition of &ldquo;untrusted&rdquo; may vary: for me, almost everything should be considered untrusted. That is how modern security works, and how mobile operating systems work. It&rsquo;s quite simple, security should be simple, and gVisor simply offers native security.</p><p>Containers are a popular, yet strange world. They revolutionized the way we make and deploy software, but one should not loose the sight of what they really are and aren&rsquo;t. This hardening guide is non-exhaustive, but I hope it can make you aware of some aspects you&rsquo;ve never thought of.</p></div><footer class=post-footer><ul class=post-tags><li><a href=https://privsec.dev/tags/operating-systems/>operating systems</a></li><li><a href=https://privsec.dev/tags/linux/>linux</a></li><li><a href=https://privsec.dev/tags/container/>container</a></li><li><a href=https://privsec.dev/tags/security/>security</a></li></ul><nav class=paginav><a class=next href=https://privsec.dev/os/linux-insecurities/><span class=title>Next »</span><br><span>Linux Insecurities</span></a></nav></footer></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+</code></pre><p>Linux 4.4.0 is shown because that is the version of the Linux API that Sentry tries to mimic. As you&rsquo;ve probably guessed, you&rsquo;re not really using Linux 4.4.0, but the application kernel that behaves like it. By the way, gVisor is of course compatible with cgroups.</p><h2 id=conclusion-whats-a-container-after-all>Conclusion: what&rsquo;s a container after all?<a hidden class=anchor aria-hidden=true href=#conclusion-whats-a-container-after-all>#</a></h2><p>Like I wrote above, a container is mostly defined by its semantics and ecosystem. Containers shouldn&rsquo;t be solely defined by the OCI reference runtime implementation, as we&rsquo;ve seen with gVisor that provides an entirely different security model.</p><p>Still not convinced? What if I told you a container can leverage the same technologies as a virtual machine? That is exactly what <a href=https://katacontainers.io/>Kata Containers</a> does by using a VMM like QEMU-lite to provide containers that are in fact lightweight virtual machines, with their traditional resources and security model, compatibility with container semantics and toolset, and an optimized overhead. While not in the OCI ecosystem, Amazon achieves quite the same with <a href=https://firecracker-microvm.github.io/>Firecracker</a>.</p><p>If you&rsquo;re running untrusted workloads, I highly suggest you consider gVisor instead of a traditional container runtime. Your definition of &ldquo;untrusted&rdquo; may vary: for me, almost everything should be considered untrusted. That is how modern security works, and how mobile operating systems work. It&rsquo;s quite simple, security should be simple, and gVisor simply offers native security.</p><p>Containers are a popular, yet strange world. They revolutionized the way we make and deploy software, but one should not loose the sight of what they really are and aren&rsquo;t. This hardening guide is non-exhaustive, but I hope it can make you aware of some aspects you&rsquo;ve never thought of.</p></div><footer class=post-footer><ul class=post-tags><li><a href=https://privsec.dev/tags/operating-systems/>operating systems</a></li><li><a href=https://privsec.dev/tags/linux/>linux</a></li><li><a href=https://privsec.dev/tags/container/>container</a></li><li><a href=https://privsec.dev/tags/security/>security</a></li></ul><nav class=paginav><a class=prev href=https://privsec.dev/os/choosing-your-desktop-linux-distribution/><span class=title>« Prev</span><br><span>Choosing Your Desktop Linux Distribution</span></a>
+<a class=next href=https://privsec.dev/os/linux-insecurities/><span class=title>Next »</span><br><span>Linux Insecurities</span></a></nav></footer></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
         <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script><script>document.querySelectorAll("pre > code").forEach(e=>{const n=e.parentNode.parentNode,t=document.createElement("button");t.classList.add("copy-code"),t.innerHTML="copy";function s(){t.innerHTML="copied!",setTimeout(()=>{t.innerHTML="copy"},2e3)}t.addEventListener("click",t=>{if("clipboard"in navigator){navigator.clipboard.writeText(e.textContent),s();return}const n=document.createRange();n.selectNodeContents(e);const o=window.getSelection();o.removeAllRanges(),o.addRange(n);try{document.execCommand("copy"),s()}catch{}o.removeRange(n)}),n.classList.contains("highlight")?n.appendChild(t):n.parentNode.firstChild==n||(e.parentNode.parentNode.parentNode.parentNode.parentNode.nodeName=="TABLE"?e.parentNode.parentNode.parentNode.parentNode.parentNode.appendChild(t):e.parentNode.appendChild(t))})</script></body></html>
\ No newline at end of file
diff --git a/public/os/index.html b/public/os/index.html
index 2b7dea7..cb68140 100644
--- a/public/os/index.html
+++ b/public/os/index.html
@@ -1,9 +1,11 @@
 <!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>Operating Systems | PrivSec.dev</title><meta name=keywords content><meta name=description content="Operating Systems - PrivSec.dev"><meta name=author content="PrivSec Team"><link rel=canonical href=https://privsec.dev/os/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><link rel=alternate type=application/rss+xml href=https://privsec.dev/os/index.xml><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="Operating Systems"><meta property="og:description" content><meta property="og:type" content="website"><meta property="og:url" content="https://privsec.dev/os/"><meta name=twitter:card content="summary"><meta name=twitter:title content="Operating Systems"><meta name=twitter:description content><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Operating Systems","item":"https://privsec.dev/os/"}]}</script></head><body class="list dark" id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span class=active>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><header class=page-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a></div><h1>Operating Systems
-<a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class=post-entry><header class=entry-header><h2>Docker and OCI Hardening</h2></header><div class=entry-content><p>Containers aren’t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:
+<a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class=post-entry><header class=entry-header><h2>Choosing Your Desktop Linux Distribution</h2></header><div class=entry-content><p>Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer....</p></div><footer class=entry-footer>5 min&nbsp;·&nbsp;944 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Choosing Your Desktop Linux Distribution" href=https://privsec.dev/os/choosing-your-desktop-linux-distribution/></a></article><article class=post-entry><header class=entry-header><h2>Docker and OCI Hardening</h2></header><div class=entry-content><p>Containers aren’t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:
 - Hey, your software doesn’t work…
 - Sorry, it works on my computer! Can’t help you.
 Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries....</p></div><footer class=entry-footer>19 min&nbsp;·&nbsp;3925 words&nbsp;·&nbsp;Wonderfall</footer><a class=entry-link aria-label="post link to Docker and OCI Hardening" href=https://privsec.dev/os/docker-and-oci-hardening/></a></article><article class=post-entry><header class=entry-header><h2>Linux Insecurities</h2></header><div class=entry-content><p>There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.
-There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post....</p></div><footer class=entry-footer>1 min&nbsp;·&nbsp;86 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Linux Insecurities" href=https://privsec.dev/os/linux-insecurities/></a></article><article class=post-entry><header class=entry-header><h2>Securing OpenSSH with FIDO2</h2></header><div class=entry-content><p>Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they’re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They’re also easier to manage while enabling a form of decentralized authentication (it’s easy and painless to revoke them). So, what’s the next step? And more exactly, why would one need something even better?
+There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post....</p></div><footer class=entry-footer>2 min&nbsp;·&nbsp;238 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Linux Insecurities" href=https://privsec.dev/os/linux-insecurities/></a></article><article class=post-entry><header class=entry-header><h2>Securing OpenSSH with FIDO2</h2></header><div class=entry-content><p>Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they’re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They’re also easier to manage while enabling a form of decentralized authentication (it’s easy and painless to revoke them). So, what’s the next step? And more exactly, why would one need something even better?
 Why? The main problem with SSH keys is that they’re not magic: they consist of a key pair, of which the private key is stored on your disk....</p></div><footer class=entry-footer>5 min&nbsp;·&nbsp;863 words&nbsp;·&nbsp;Wonderfall</footer><a class=entry-link aria-label="post link to Securing OpenSSH with FIDO2" href=https://privsec.dev/os/securing-openssh-with-fido2/></a></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
diff --git a/public/os/index.xml b/public/os/index.xml
index 4b496a4..60a34f9 100644
--- a/public/os/index.xml
+++ b/public/os/index.xml
@@ -5,6 +5,17 @@
     <link>https://privsec.dev/os/</link>
     <description>Recent content in Operating Systems on PrivSec.dev</description>
     <generator>Hugo -- gohugo.io</generator><atom:link href="https://privsec.dev/os/index.xml" rel="self" type="application/rss+xml" />
+    <item>
+      <title>Choosing Your Desktop Linux Distribution</title>
+      <link>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</link>
+      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
+      
+      <guid>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</guid>
+      <description>Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer.</description>
+    </item>
+    
     <item>
       <title>Docker and OCI Hardening</title>
       <link>https://privsec.dev/os/docker-and-oci-hardening/</link>
diff --git a/public/os/linux-insecurities/index.html b/public/os/linux-insecurities/index.html
index ad856d0..180bc61 100644
--- a/public/os/linux-insecurities/index.html
+++ b/public/os/linux-insecurities/index.html
@@ -2,7 +2,7 @@
 There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix&rsquo;s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post."><meta name=author content="Tommy"><link rel=canonical href=https://privsec.dev/os/linux-insecurities/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><script defer crossorigin=anonymous src=/assets/js/highlight.f413e19d0714851f6474e7ee9632408e58ac146fbdbe62747134bea2fa3415e0.js integrity="sha256-9BPhnQcUhR9kdOfuljJAjlisFG+9vmJ0cTS+ovo0FeA=" onload=hljs.initHighlightingOnLoad()></script>
 <link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="Linux Insecurities"><meta property="og:description" content="There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.
 There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix&rsquo;s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post."><meta property="og:type" content="article"><meta property="og:url" content="https://privsec.dev/os/linux-insecurities/"><meta property="article:section" content="os"><meta name=twitter:card content="summary"><meta name=twitter:title content="Linux Insecurities"><meta name=twitter:description content="There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.
-There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix&rsquo;s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Operating Systems","item":"https://privsec.dev/os/"},{"@type":"ListItem","position":3,"name":"Linux Insecurities","item":"https://privsec.dev/os/linux-insecurities/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Linux Insecurities","name":"Linux Insecurities","description":"There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.\nThere is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix\u0026rsquo;s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post.","keywords":["operating system","security","linux"],"articleBody":"There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.\nThere is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post. You can find the original article here.\n","wordCount":"86","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Tommy"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/os/linux-insecurities/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/os/>Operating Systems</a></div><h1 class=post-title>Linux Insecurities</h1><div class=post-meta>1 min&nbsp;·&nbsp;86 words&nbsp;·&nbsp;Tommy&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/content/os/Linux%20Insecurities.md rel="noopener noreferrer" target=_blank>Suggest Changes</a></div></header><div class=post-content><p>There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.</p><p>There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, <a href=https://www.whonix.org/>Whonix</a>&rsquo;s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post. You can find the original article <a href=https://madaidans-insecurities.github.io/linux.html>here</a>.</p></div><footer class=post-footer><ul class=post-tags><li><a href=https://privsec.dev/tags/operating-system/>operating system</a></li><li><a href=https://privsec.dev/tags/security/>security</a></li><li><a href=https://privsec.dev/tags/linux/>linux</a></li></ul><nav class=paginav><a class=prev href=https://privsec.dev/os/docker-and-oci-hardening/><span class=title>« Prev</span><br><span>Docker and OCI Hardening</span></a>
+There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix&rsquo;s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Operating Systems","item":"https://privsec.dev/os/"},{"@type":"ListItem","position":3,"name":"Linux Insecurities","item":"https://privsec.dev/os/linux-insecurities/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Linux Insecurities","name":"Linux Insecurities","description":"There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.\nThere is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix\u0026rsquo;s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post.","keywords":["operating system","security","linux"],"articleBody":"There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.\nThere is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post. You can find the original article here.\nWhy is Linux used on servers if it is so insecure? On servers, while most of the problems referenced in the article still exists, they are somewhat less problematic.\nOn Desktop Linux, GUI applications run under your user, and thus have access to all of your files in /home. This is in contrast to how system daemons typically run on servers, where they have their own group and user. For example, NGINX will run under nginx:nginx on Red Hat distributions, or www-data:www-data on Debian based ones. Discreationary Access Control does help with filesystem access control for server processes, but is useless for desktop applications.\nAnother thing to keep in mind is that Mandatory Access Control is also somewhat effective on servers, as commonly run system daemons are confined.\nWork in progress\nCan’t Linux be configured to be most secure operating system? Isn’t it impossible to backdoor Linux because it is open source? ","wordCount":"238","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Tommy"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/os/linux-insecurities/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/os/>Operating Systems</a></div><h1 class=post-title>Linux Insecurities</h1><div class=post-meta>2 min&nbsp;·&nbsp;238 words&nbsp;·&nbsp;Tommy&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/blob/main/content/os/Linux%20Insecurities.md rel="noopener noreferrer" target=_blank>Suggest Changes</a></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#why-is-linux-used-on-servers-if-it-is-so-insecure aria-label="Why is Linux used on servers if it is so insecure?">Why is Linux used on servers if it is so insecure?</a></li><li><a href=#cant-linux-be-configured-to-be-most-secure-operating-system aria-label="Can&amp;rsquo;t Linux be configured to be most secure operating system?">Can&rsquo;t Linux be configured to be most secure operating system?</a></li><li><a href=#isnt-it-impossible-to-backdoor-linux-because-it-is-open-source aria-label="Isn&amp;rsquo;t it impossible to backdoor Linux because it is open source?">Isn&rsquo;t it impossible to backdoor Linux because it is open source?</a></li></ul></div></details></div><div class=post-content><p>There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.</p><p>There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, <a href=https://www.whonix.org/>Whonix</a>&rsquo;s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post. You can find the original article <a href=https://madaidans-insecurities.github.io/linux.html>here</a>.</p><h3 id=why-is-linux-used-on-servers-if-it-is-so-insecure>Why is Linux used on servers if it is so insecure?<a hidden class=anchor aria-hidden=true href=#why-is-linux-used-on-servers-if-it-is-so-insecure>#</a></h3><p>On servers, while most of the problems referenced in the article still exists, they are somewhat less problematic.</p><p>On Desktop Linux, GUI applications run under your user, and thus have access to all of your files in <code>/home</code>. This is in contrast to how system daemons typically run on servers, where they have their own group and user. For example, NGINX will run under <code>nginx:nginx</code> on Red Hat distributions, or <code>www-data:www-data</code> on Debian based ones. Discreationary Access Control does help with filesystem access control for server processes, but is useless for desktop applications.</p><p>Another thing to keep in mind is that Mandatory Access Control is also somewhat effective on servers, as commonly run system daemons are confined.</p><p>Work in progress</p><h3 id=cant-linux-be-configured-to-be-most-secure-operating-system>Can&rsquo;t Linux be configured to be most secure operating system?<a hidden class=anchor aria-hidden=true href=#cant-linux-be-configured-to-be-most-secure-operating-system>#</a></h3><h3 id=isnt-it-impossible-to-backdoor-linux-because-it-is-open-source>Isn&rsquo;t it impossible to backdoor Linux because it is open source?<a hidden class=anchor aria-hidden=true href=#isnt-it-impossible-to-backdoor-linux-because-it-is-open-source>#</a></h3></div><footer class=post-footer><ul class=post-tags><li><a href=https://privsec.dev/tags/operating-system/>operating system</a></li><li><a href=https://privsec.dev/tags/security/>security</a></li><li><a href=https://privsec.dev/tags/linux/>linux</a></li></ul><nav class=paginav><a class=prev href=https://privsec.dev/os/docker-and-oci-hardening/><span class=title>« Prev</span><br><span>Docker and OCI Hardening</span></a>
 <a class=next href=https://privsec.dev/os/securing-openssh-with-fido2/><span class=title>Next »</span><br><span>Securing OpenSSH with FIDO2</span></a></nav></footer></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
diff --git a/public/os/securing-openssh-with-fido2/index.html b/public/os/securing-openssh-with-fido2/index.html
index 8bb2c74..8e96d9b 100644
--- a/public/os/securing-openssh-with-fido2/index.html
+++ b/public/os/securing-openssh-with-fido2/index.html
@@ -2,7 +2,7 @@
 Why? The main problem with SSH keys is that they&rsquo;re not magic: they consist of a key pair, of which the private key is stored on your disk."><meta name=author content="Wonderfall"><link rel=canonical href=https://wonderfall.dev/openssh-fido2/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><script defer crossorigin=anonymous src=/assets/js/highlight.f413e19d0714851f6474e7ee9632408e58ac146fbdbe62747134bea2fa3415e0.js integrity="sha256-9BPhnQcUhR9kdOfuljJAjlisFG+9vmJ0cTS+ovo0FeA=" onload=hljs.initHighlightingOnLoad()></script>
 <link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="Securing OpenSSH with FIDO2"><meta property="og:description" content="Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they&rsquo;re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They&rsquo;re also easier to manage while enabling a form of decentralized authentication (it&rsquo;s easy and painless to revoke them). So, what&rsquo;s the next step? And more exactly, why would one need something even better?
 Why? The main problem with SSH keys is that they&rsquo;re not magic: they consist of a key pair, of which the private key is stored on your disk."><meta property="og:type" content="article"><meta property="og:url" content="https://privsec.dev/os/securing-openssh-with-fido2/"><meta property="article:section" content="os"><meta name=twitter:card content="summary"><meta name=twitter:title content="Securing OpenSSH with FIDO2"><meta name=twitter:description content="Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they&rsquo;re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They&rsquo;re also easier to manage while enabling a form of decentralized authentication (it&rsquo;s easy and painless to revoke them). So, what&rsquo;s the next step? And more exactly, why would one need something even better?
-Why? The main problem with SSH keys is that they&rsquo;re not magic: they consist of a key pair, of which the private key is stored on your disk."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Operating Systems","item":"https://privsec.dev/os/"},{"@type":"ListItem","position":3,"name":"Securing OpenSSH with FIDO2","item":"https://privsec.dev/os/securing-openssh-with-fido2/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Securing OpenSSH with FIDO2","name":"Securing OpenSSH with FIDO2","description":"Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they\u0026rsquo;re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They\u0026rsquo;re also easier to manage while enabling a form of decentralized authentication (it\u0026rsquo;s easy and painless to revoke them). So, what\u0026rsquo;s the next step? And more exactly, why would one need something even better?\nWhy? The main problem with SSH keys is that they\u0026rsquo;re not magic: they consist of a key pair, of which the private key is stored on your disk.","keywords":["operating systems","linux","security"],"articleBody":"Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they’re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They’re also easier to manage while enabling a form of decentralized authentication (it’s easy and painless to revoke them). So, what’s the next step? And more exactly, why would one need something even better?\nWhy? The main problem with SSH keys is that they’re not magic: they consist of a key pair, of which the private key is stored on your disk. You should be wary of various exfiltration attempts, depending on your theat model:\nIf your disk is not encrypted, any physical access could compromise your keys. If your private key isn’t encrypted, malicious applications could compromise it. Even with both encrypted, malicious applications could register your keystrokes. All these attempts are particularly a thing on desktop platforms, because they don’t have a proper sandboxing model. On Windows, non-UWP apps could likely have full access to your .ssh directory. On desktop Linux distributions, sandboxing is also lacking, and the situation is even worse if you’re using X.org since it allows apps to spy on each other (and on your keyboard) by design. A first good step would be to only use SSH from a trusted \u0026 decently secure system.\nAnother layer of defense would obviously be multi-factor authentification, or the fact that you’re relying on a shared secret instead. We can use FIDO2 security keys for that. That way, even if your private key is compromised, the attacker needs physical access to your security key. TOTP is another common 2FA technique, but it’s vulnerable to various attacks, and relies on the quality of the implementation on the server.\nHow? Fortunately for us, OpenSSH 8.2 (released in February 2020) introduced native support for FIDO2/U2F. Most OpenSSH distributions should have the middleware set to use the libfido2 library, including portable versions such as the one for Win32.\nBasically, ssh-keygen -t ${key_type}-sk will generate for us a token-backed key pair. The key types that are supported depend on your security key. Newer models should support both ECDSA-P256 (ecdsa-sk) and Ed25519 (ed25519-sk). If the latter is available, you should prefer it.\nClient configuration To get started:\nssh-keygen -t ed25519-sk This will generate a id_ed25519_sk private key and a id_ed25519_sk.pub public key in .ssh. These are defaults, but you can change them if you want. We will call this key pair a “handle”, because they’re not sufficient by themselves to derive the real secret (as you guessed it, the FIDO2 token is needed). ssh-keygen should ask you to touch the key, and enter the PIN prior to that if you did set one (you probably should).\nYou can also generate a resident key (referred to as discoverable credential in the WebAuthn specification):\nssh-keygen -t ed25519-sk -O resident -O application=ssh:user1 As you can see, a few options must be specified:\n-O resident will tell ssh-keygen to generate a resident key, meaning that the private “handle” key will also be stored on the security key itself. This has security implications, but you may want that to move seamlessly between different computers. In that case, you should absolutely protect your key with a PIN beforehand. -O application=ssh: is necessary to instruct that the resident key will use a particular slot, because the security key will have to index the resident keys (by default, they use ssh: with an empty user ID). If this is not specificed, the next key generation might overwrite the previous one. -O verify-required is optional but instructs that a PIN is required to generate/access the key. Resident keys can be retrieved using ssh-keygen -K or ssh-add -K if you don’t want to write them to the disk.\nServer configuration Next, transfer your public key over to the server (granted you have already access to it with a regular key pair):\nssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@server.domain.tld Ta-da! But one last thing: we need to make sure the server supports this public key format in sshd_config:\nPubkeyAcceptedKeyTypes ssh-ed25519,sk-ssh-ed25519@openssh.com Adding sk-ssh-ed25519@openssh.com to PubkeyAcceptedKeyTypes should suffice. It’s best practice to only use the cryptographic primitives that you need, and hopefully ones that are also modern. This isn’t a full-on SSH hardening guide, but you should take a look at the configuration file GrapheneOS uses for their servers to give you an idea on a few good practices.\nRestart the sshd service and try to connect to your server using your key handle (by passing -i ~/.ssh/id_ed25519_sk to ssh for instance). If that works for you (your FIDO2 security key should be needed to derive the real secret), feel free to remove your previous keys from .ssh/authorized_keys on your server.\nThat’s cool, right? If you don’t have a security key, you can buy one from YubiKey (I’m very happy with my 5C NFC by the way), Nitrokey, SoloKeys or OnlyKey (to name a few). If you have an Android device with a hardware security module (HSM), such as the Google Pixels equipped with Titan M (Pixel 3+), you could even use them as bluetooth security keys.\nNo reason to miss out on the party if you can afford it!\n","wordCount":"863","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Wonderfall"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/os/securing-openssh-with-fido2/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/os/>Operating Systems</a></div><h1 class=post-title>Securing OpenSSH with FIDO2</h1><div class=post-meta>5 min&nbsp;·&nbsp;863 words&nbsp;·&nbsp;Wonderfall&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/content/os/Securing%20OpenSSH%20with%20FIDO2.md rel="noopener noreferrer" target=_blank>Suggest Changes</a>
+Why? The main problem with SSH keys is that they&rsquo;re not magic: they consist of a key pair, of which the private key is stored on your disk."><script type=application/ld+json>{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":2,"name":"Operating Systems","item":"https://privsec.dev/os/"},{"@type":"ListItem","position":3,"name":"Securing OpenSSH with FIDO2","item":"https://privsec.dev/os/securing-openssh-with-fido2/"}]}</script><script type=application/ld+json>{"@context":"https://schema.org","@type":"BlogPosting","headline":"Securing OpenSSH with FIDO2","name":"Securing OpenSSH with FIDO2","description":"Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they\u0026rsquo;re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They\u0026rsquo;re also easier to manage while enabling a form of decentralized authentication (it\u0026rsquo;s easy and painless to revoke them). So, what\u0026rsquo;s the next step? And more exactly, why would one need something even better?\nWhy? The main problem with SSH keys is that they\u0026rsquo;re not magic: they consist of a key pair, of which the private key is stored on your disk.","keywords":["operating systems","linux","security"],"articleBody":"Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they’re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They’re also easier to manage while enabling a form of decentralized authentication (it’s easy and painless to revoke them). So, what’s the next step? And more exactly, why would one need something even better?\nWhy? The main problem with SSH keys is that they’re not magic: they consist of a key pair, of which the private key is stored on your disk. You should be wary of various exfiltration attempts, depending on your theat model:\nIf your disk is not encrypted, any physical access could compromise your keys. If your private key isn’t encrypted, malicious applications could compromise it. Even with both encrypted, malicious applications could register your keystrokes. All these attempts are particularly a thing on desktop platforms, because they don’t have a proper sandboxing model. On Windows, non-UWP apps could likely have full access to your .ssh directory. On desktop Linux distributions, sandboxing is also lacking, and the situation is even worse if you’re using X.org since it allows apps to spy on each other (and on your keyboard) by design. A first good step would be to only use SSH from a trusted \u0026 decently secure system.\nAnother layer of defense would obviously be multi-factor authentification, or the fact that you’re relying on a shared secret instead. We can use FIDO2 security keys for that. That way, even if your private key is compromised, the attacker needs physical access to your security key. TOTP is another common 2FA technique, but it’s vulnerable to various attacks, and relies on the quality of the implementation on the server.\nHow? Fortunately for us, OpenSSH 8.2 (released in February 2020) introduced native support for FIDO2/U2F. Most OpenSSH distributions should have the middleware set to use the libfido2 library, including portable versions such as the one for Win32.\nBasically, ssh-keygen -t ${key_type}-sk will generate for us a token-backed key pair. The key types that are supported depend on your security key. Newer models should support both ECDSA-P256 (ecdsa-sk) and Ed25519 (ed25519-sk). If the latter is available, you should prefer it.\nClient configuration To get started:\nssh-keygen -t ed25519-sk This will generate a id_ed25519_sk private key and a id_ed25519_sk.pub public key in .ssh. These are defaults, but you can change them if you want. We will call this key pair a “handle”, because they’re not sufficient by themselves to derive the real secret (as you guessed it, the FIDO2 token is needed). ssh-keygen should ask you to touch the key, and enter the PIN prior to that if you did set one (you probably should).\nYou can also generate a resident key (referred to as discoverable credential in the WebAuthn specification):\nssh-keygen -t ed25519-sk -O resident -O application=ssh:user1 As you can see, a few options must be specified:\n-O resident will tell ssh-keygen to generate a resident key, meaning that the private “handle” key will also be stored on the security key itself. This has security implications, but you may want that to move seamlessly between different computers. In that case, you should absolutely protect your key with a PIN beforehand. -O application=ssh: is necessary to instruct that the resident key will use a particular slot, because the security key will have to index the resident keys (by default, they use ssh: with an empty user ID). If this is not specificed, the next key generation might overwrite the previous one. -O verify-required is optional but instructs that a PIN is required to generate/access the key. Resident keys can be retrieved using ssh-keygen -K or ssh-add -K if you don’t want to write them to the disk.\nServer configuration Next, transfer your public key over to the server (granted you have already access to it with a regular key pair):\nssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@server.domain.tld Ta-da! But one last thing: we need to make sure the server supports this public key format in sshd_config:\nPubkeyAcceptedKeyTypes ssh-ed25519,sk-ssh-ed25519@openssh.com Adding sk-ssh-ed25519@openssh.com to PubkeyAcceptedKeyTypes should suffice. It’s best practice to only use the cryptographic primitives that you need, and hopefully ones that are also modern. This isn’t a full-on SSH hardening guide, but you should take a look at the configuration file GrapheneOS uses for their servers to give you an idea on a few good practices.\nRestart the sshd service and try to connect to your server using your key handle (by passing -i ~/.ssh/id_ed25519_sk to ssh for instance). If that works for you (your FIDO2 security key should be needed to derive the real secret), feel free to remove your previous keys from .ssh/authorized_keys on your server.\nThat’s cool, right? If you don’t have a security key, you can buy one from YubiKey (I’m very happy with my 5C NFC by the way), Nitrokey, SoloKeys or OnlyKey (to name a few). If you have an Android device with a hardware security module (HSM), such as the Google Pixels equipped with Titan M (Pixel 3+), you could even use them as bluetooth security keys.\nNo reason to miss out on the party if you can afford it!\n","wordCount":"863","inLanguage":"en","datePublished":"0001-01-01T00:00:00Z","dateModified":"0001-01-01T00:00:00Z","author":{"@type":"Person","name":"Wonderfall"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://privsec.dev/os/securing-openssh-with-fido2/"},"publisher":{"@type":"Organization","name":"PrivSec.dev","logo":{"@type":"ImageObject","url":"https://privsec.dev/%3Clink%20/%20abs%20url%3E"}}}</script></head><body class=dark id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><article class=post-single><header class=post-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/os/>Operating Systems</a></div><h1 class=post-title>Securing OpenSSH with FIDO2</h1><div class=post-meta>5 min&nbsp;·&nbsp;863 words&nbsp;·&nbsp;Wonderfall&nbsp;|&nbsp;<a href=https://github.com/PrivSec-dev/privsec.dev/blob/main/content/os/Securing%20OpenSSH%20with%20FIDO2.md rel="noopener noreferrer" target=_blank>Suggest Changes</a>
 &nbsp;|&nbsp;<span>Originally published at&nbsp;<a href=https://wonderfall.dev/openssh-fido2/ title=https://wonderfall.dev/openssh-fido2/ target=_blank rel="noopener noreferrer">wonderfall.dev</a></span></div></header><div class=toc><details><summary accesskey=c title="(Alt + C)"><span class=details>Table of Contents</span></summary><div class=inner><ul><li><a href=#why aria-label=Why?>Why?</a></li><li><a href=#how aria-label=How?>How?</a><ul><li><a href=#client-configuration aria-label="Client configuration">Client configuration</a></li><li><a href=#server-configuration aria-label="Server configuration">Server configuration</a></li></ul></li><li><a href=#thats-cool-right aria-label="That&amp;rsquo;s cool, right?">That&rsquo;s cool, right?</a></li></ul></div></details></div><div class=post-content><p>Passwordless authentication with OpenSSH keys has been the <em>de facto</em> security standard for years. SSH keys are more robust since they&rsquo;re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They&rsquo;re also easier to manage while enabling a form of decentralized authentication (it&rsquo;s easy and painless to revoke them). So, what&rsquo;s the next step? And more exactly, why would one need something even better?</p><h2 id=why>Why?<a hidden class=anchor aria-hidden=true href=#why>#</a></h2><p>The main problem with SSH keys is that they&rsquo;re not magic: they consist of a key pair, of which the private key is stored on your disk. You should be wary of various exfiltration attempts, depending on your theat model:</p><ul><li>If your disk is not encrypted, any physical access could compromise your keys.</li><li>If your private key isn&rsquo;t encrypted, malicious applications could compromise it.</li><li>Even with both encrypted, malicious applications could register your keystrokes.</li></ul><p>All these attempts are particularly a thing on desktop platforms, because they don&rsquo;t have a proper sandboxing model. On Windows, non-UWP apps could likely have full access to your <code>.ssh</code> directory. On desktop Linux distributions, sandboxing is also lacking, and the situation is even worse if you&rsquo;re using X.org since it allows apps to spy on each other (and on your keyboard) by design. A first good step would be to only use SSH from a trusted & decently secure system.</p><p>Another layer of defense would obviously be multi-factor authentification, or the fact that you&rsquo;re relying on a shared secret instead. We can use FIDO2 security keys for that. That way, even if your private key is compromised, the attacker needs physical access to your security key. TOTP is another common 2FA technique, but it&rsquo;s vulnerable to various attacks, and relies on the quality of the implementation on the server.</p><h2 id=how>How?<a hidden class=anchor aria-hidden=true href=#how>#</a></h2><p>Fortunately for us, <a href=https://www.openssh.com/txt/release-8.2>OpenSSH 8.2</a> (released in February 2020) introduced native support for FIDO2/U2F. Most OpenSSH distributions should have the middleware set to use the <code>libfido2</code> library, including portable versions such as the one <a href=https://github.com/PowerShell/Win32-OpenSSH>for Win32</a>.</p><p>Basically, <code>ssh-keygen -t ${key_type}-sk</code> will generate for us a token-backed key pair. The key types that are supported depend on your security key. Newer models should support both ECDSA-P256 (<code>ecdsa-sk</code>) and Ed25519 (<code>ed25519-sk</code>). If the latter is available, you should prefer it.</p><h3 id=client-configuration>Client configuration<a hidden class=anchor aria-hidden=true href=#client-configuration>#</a></h3><p>To get started:</p><pre tabindex=0><code>ssh-keygen -t ed25519-sk
 </code></pre><p>This will generate a <code>id_ed25519_sk</code> private key and a <code>id_ed25519_sk.pub</code> public key in <code>.ssh</code>. These are defaults, but you can change them if you want. We will call this key pair a &ldquo;handle&rdquo;, because they&rsquo;re not sufficient by themselves to derive the real secret (as you guessed it, the FIDO2 token is needed). <code>ssh-keygen</code> should ask you to touch the key, and enter the PIN prior to that if you did set one (you probably should).</p><p>You can also generate a <strong>resident key</strong> (referred to as <em>discoverable credential</em> in the WebAuthn specification):</p><pre tabindex=0><code>ssh-keygen -t ed25519-sk -O resident -O application=ssh:user1
 </code></pre><p>As you can see, a few options must be specified:</p><ul><li><code>-O resident</code> will tell <code>ssh-keygen</code> to generate a resident key, meaning that the private &ldquo;handle&rdquo; key will also be stored on the security key itself. This has security implications, but you may want that to move seamlessly between different computers. In that case, you should absolutely protect your key with a PIN beforehand.</li><li><code>-O application=ssh:</code> is necessary to instruct that the resident key will use a particular slot, because the security key will have to index the resident keys (by default, they use <code>ssh:</code> with an empty user ID). If this is not specificed, the next key generation might overwrite the previous one.</li><li><code>-O verify-required</code> is optional but instructs that a PIN is required to generate/access the key.</li></ul><p>Resident keys can be retrieved using <code>ssh-keygen -K</code> or <code>ssh-add -K</code> if you don&rsquo;t want to write them to the disk.</p><h3 id=server-configuration>Server configuration<a hidden class=anchor aria-hidden=true href=#server-configuration>#</a></h3><p>Next, transfer your public key over to the server (granted you have already access to it with a regular key pair):</p><pre tabindex=0><code>ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@server.domain.tld
diff --git a/public/sitemap.xml b/public/sitemap.xml
index 7c5a602..c8896e6 100644
--- a/public/sitemap.xml
+++ b/public/sitemap.xml
@@ -9,6 +9,8 @@
     <loc>https://privsec.dev/apps/</loc>
   </url><url>
     <loc>https://privsec.dev/categories/</loc>
+  </url><url>
+    <loc>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</loc>
   </url><url>
     <loc>https://privsec.dev/tags/container/</loc>
   </url><url>
diff --git a/public/tags/index.html b/public/tags/index.html
index 05a0ab8..7908d06 100644
--- a/public/tags/index.html
+++ b/public/tags/index.html
@@ -1,4 +1,4 @@
-<!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>Tags | PrivSec.dev</title><meta name=keywords content><meta name=description content><meta name=author content="PrivSec Team"><link rel=canonical href=https://privsec.dev/tags/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><link rel=alternate type=application/rss+xml href=https://privsec.dev/tags/index.xml><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="Tags"><meta property="og:description" content><meta property="og:type" content="website"><meta property="og:url" content="https://privsec.dev/tags/"><meta name=twitter:card content="summary"><meta name=twitter:title content="Tags"><meta name=twitter:description content></head><body class="list dark" id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><header class=page-header><h1>Tags</h1></header><ul class=terms-tags><li><a href=https://privsec.dev/tags/android/>android <sup><strong><sup>1</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/container/>container <sup><strong><sup>1</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/knowledge-base/>knowledge base <sup><strong><sup>1</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/linux/>linux <sup><strong><sup>3</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/operating-system/>operating system <sup><strong><sup>1</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/operating-systems/>operating systems <sup><strong><sup>2</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/security/>security <sup><strong><sup>5</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/software/>software <sup><strong><sup>1</sup></strong></sup></a></li></ul></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+<!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>Tags | PrivSec.dev</title><meta name=keywords content><meta name=description content><meta name=author content="PrivSec Team"><link rel=canonical href=https://privsec.dev/tags/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><link rel=alternate type=application/rss+xml href=https://privsec.dev/tags/index.xml><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="Tags"><meta property="og:description" content><meta property="og:type" content="website"><meta property="og:url" content="https://privsec.dev/tags/"><meta name=twitter:card content="summary"><meta name=twitter:title content="Tags"><meta name=twitter:description content></head><body class="list dark" id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><header class=page-header><h1>Tags</h1></header><ul class=terms-tags><li><a href=https://privsec.dev/tags/android/>android <sup><strong><sup>1</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/container/>container <sup><strong><sup>1</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/knowledge-base/>knowledge base <sup><strong><sup>1</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/linux/>linux <sup><strong><sup>4</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/operating-system/>operating system <sup><strong><sup>2</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/operating-systems/>operating systems <sup><strong><sup>2</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/security/>security <sup><strong><sup>6</sup></strong></sup></a></li><li><a href=https://privsec.dev/tags/software/>software <sup><strong><sup>1</sup></strong></sup></a></li></ul></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
         <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script></body></html>
\ No newline at end of file
diff --git a/public/tags/knowledge-base/index.html b/public/tags/knowledge-base/index.html
index 6ba47da..f4fdd94 100644
--- a/public/tags/knowledge-base/index.html
+++ b/public/tags/knowledge-base/index.html
@@ -1,6 +1,6 @@
 <!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>knowledge base | PrivSec.dev</title><meta name=keywords content><meta name=description content><meta name=author content="PrivSec Team"><link rel=canonical href=https://privsec.dev/tags/knowledge-base/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><link rel=alternate type=application/rss+xml href=https://privsec.dev/tags/knowledge-base/index.xml><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="knowledge base"><meta property="og:description" content><meta property="og:type" content="website"><meta property="og:url" content="https://privsec.dev/tags/knowledge-base/"><meta name=twitter:card content="summary"><meta name=twitter:title content="knowledge base"><meta name=twitter:description content></head><body class="list dark" id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><header class=page-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/tags/>Tags</a></div><h1>knowledge base
 <a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class="post-entry tag-entry"><header class=entry-header><h2>Multi-factor Authentication</h2></header><div class=entry-content><p>Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.
-Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification....</p></div><footer class=entry-footer>6 min&nbsp;·&nbsp;1225 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Multi-factor Authentication" href=https://privsec.dev/knowledge/multi-factor-authentication/></a></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification....</p></div><footer class=entry-footer>6 min&nbsp;·&nbsp;1223 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Multi-factor Authentication" href=https://privsec.dev/knowledge/multi-factor-authentication/></a></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
         <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script></body></html>
\ No newline at end of file
diff --git a/public/tags/linux/index.html b/public/tags/linux/index.html
index 4a4a341..03eaa28 100644
--- a/public/tags/linux/index.html
+++ b/public/tags/linux/index.html
@@ -1,9 +1,11 @@
 <!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>linux | PrivSec.dev</title><meta name=keywords content><meta name=description content><meta name=author content="PrivSec Team"><link rel=canonical href=https://privsec.dev/tags/linux/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><link rel=alternate type=application/rss+xml href=https://privsec.dev/tags/linux/index.xml><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="linux"><meta property="og:description" content><meta property="og:type" content="website"><meta property="og:url" content="https://privsec.dev/tags/linux/"><meta name=twitter:card content="summary"><meta name=twitter:title content="linux"><meta name=twitter:description content></head><body class="list dark" id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><header class=page-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/tags/>Tags</a></div><h1>linux
-<a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class="post-entry tag-entry"><header class=entry-header><h2>Docker and OCI Hardening</h2></header><div class=entry-content><p>Containers aren’t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:
+<a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class="post-entry tag-entry"><header class=entry-header><h2>Choosing Your Desktop Linux Distribution</h2></header><div class=entry-content><p>Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer....</p></div><footer class=entry-footer>5 min&nbsp;·&nbsp;944 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Choosing Your Desktop Linux Distribution" href=https://privsec.dev/os/choosing-your-desktop-linux-distribution/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>Docker and OCI Hardening</h2></header><div class=entry-content><p>Containers aren’t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:
 - Hey, your software doesn’t work…
 - Sorry, it works on my computer! Can’t help you.
 Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries....</p></div><footer class=entry-footer>19 min&nbsp;·&nbsp;3925 words&nbsp;·&nbsp;Wonderfall</footer><a class=entry-link aria-label="post link to Docker and OCI Hardening" href=https://privsec.dev/os/docker-and-oci-hardening/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>Linux Insecurities</h2></header><div class=entry-content><p>There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.
-There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post....</p></div><footer class=entry-footer>1 min&nbsp;·&nbsp;86 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Linux Insecurities" href=https://privsec.dev/os/linux-insecurities/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>Securing OpenSSH with FIDO2</h2></header><div class=entry-content><p>Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they’re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They’re also easier to manage while enabling a form of decentralized authentication (it’s easy and painless to revoke them). So, what’s the next step? And more exactly, why would one need something even better?
+There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post....</p></div><footer class=entry-footer>2 min&nbsp;·&nbsp;238 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Linux Insecurities" href=https://privsec.dev/os/linux-insecurities/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>Securing OpenSSH with FIDO2</h2></header><div class=entry-content><p>Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they’re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They’re also easier to manage while enabling a form of decentralized authentication (it’s easy and painless to revoke them). So, what’s the next step? And more exactly, why would one need something even better?
 Why? The main problem with SSH keys is that they’re not magic: they consist of a key pair, of which the private key is stored on your disk....</p></div><footer class=entry-footer>5 min&nbsp;·&nbsp;863 words&nbsp;·&nbsp;Wonderfall</footer><a class=entry-link aria-label="post link to Securing OpenSSH with FIDO2" href=https://privsec.dev/os/securing-openssh-with-fido2/></a></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
diff --git a/public/tags/linux/index.xml b/public/tags/linux/index.xml
index a728a9c..43c61ca 100644
--- a/public/tags/linux/index.xml
+++ b/public/tags/linux/index.xml
@@ -5,6 +5,17 @@
     <link>https://privsec.dev/tags/linux/</link>
     <description>Recent content in linux on PrivSec.dev</description>
     <generator>Hugo -- gohugo.io</generator><atom:link href="https://privsec.dev/tags/linux/index.xml" rel="self" type="application/rss+xml" />
+    <item>
+      <title>Choosing Your Desktop Linux Distribution</title>
+      <link>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</link>
+      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
+      
+      <guid>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</guid>
+      <description>Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer.</description>
+    </item>
+    
     <item>
       <title>Docker and OCI Hardening</title>
       <link>https://privsec.dev/os/docker-and-oci-hardening/</link>
diff --git a/public/tags/operating-system/index.html b/public/tags/operating-system/index.html
index 73ff1f3..285434b 100644
--- a/public/tags/operating-system/index.html
+++ b/public/tags/operating-system/index.html
@@ -1,6 +1,8 @@
 <!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>operating system | PrivSec.dev</title><meta name=keywords content><meta name=description content><meta name=author content="PrivSec Team"><link rel=canonical href=https://privsec.dev/tags/operating-system/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><link rel=alternate type=application/rss+xml href=https://privsec.dev/tags/operating-system/index.xml><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="operating system"><meta property="og:description" content><meta property="og:type" content="website"><meta property="og:url" content="https://privsec.dev/tags/operating-system/"><meta name=twitter:card content="summary"><meta name=twitter:title content="operating system"><meta name=twitter:description content></head><body class="list dark" id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><header class=page-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/tags/>Tags</a></div><h1>operating system
-<a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class="post-entry tag-entry"><header class=entry-header><h2>Linux Insecurities</h2></header><div class=entry-content><p>There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.
-There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post....</p></div><footer class=entry-footer>1 min&nbsp;·&nbsp;86 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Linux Insecurities" href=https://privsec.dev/os/linux-insecurities/></a></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+<a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class="post-entry tag-entry"><header class=entry-header><h2>Choosing Your Desktop Linux Distribution</h2></header><div class=entry-content><p>Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer....</p></div><footer class=entry-footer>5 min&nbsp;·&nbsp;944 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Choosing Your Desktop Linux Distribution" href=https://privsec.dev/os/choosing-your-desktop-linux-distribution/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>Linux Insecurities</h2></header><div class=entry-content><p>There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.
+There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post....</p></div><footer class=entry-footer>2 min&nbsp;·&nbsp;238 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Linux Insecurities" href=https://privsec.dev/os/linux-insecurities/></a></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
         <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script></body></html>
\ No newline at end of file
diff --git a/public/tags/operating-system/index.xml b/public/tags/operating-system/index.xml
index 08fb0e6..c3ce661 100644
--- a/public/tags/operating-system/index.xml
+++ b/public/tags/operating-system/index.xml
@@ -5,6 +5,17 @@
     <link>https://privsec.dev/tags/operating-system/</link>
     <description>Recent content in operating system on PrivSec.dev</description>
     <generator>Hugo -- gohugo.io</generator><atom:link href="https://privsec.dev/tags/operating-system/index.xml" rel="self" type="application/rss+xml" />
+    <item>
+      <title>Choosing Your Desktop Linux Distribution</title>
+      <link>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</link>
+      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
+      
+      <guid>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</guid>
+      <description>Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer.</description>
+    </item>
+    
     <item>
       <title>Linux Insecurities</title>
       <link>https://privsec.dev/os/linux-insecurities/</link>
diff --git a/public/tags/security/index.html b/public/tags/security/index.html
index 8ff9f0a..e21ba75 100644
--- a/public/tags/security/index.html
+++ b/public/tags/security/index.html
@@ -1,13 +1,14 @@
 <!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>security | PrivSec.dev</title><meta name=keywords content><meta name=description content><meta name=author content="PrivSec Team"><link rel=canonical href=https://privsec.dev/tags/security/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><link rel=alternate type=application/rss+xml href=https://privsec.dev/tags/security/index.xml><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="security"><meta property="og:description" content><meta property="og:type" content="website"><meta property="og:url" content="https://privsec.dev/tags/security/"><meta name=twitter:card content="summary"><meta name=twitter:title content="security"><meta name=twitter:description content></head><body class="list dark" id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><header class=page-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/tags/>Tags</a></div><h1>security
-<a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class="post-entry tag-entry"><header class=entry-header><h2>Docker and OCI Hardening</h2></header><div class=entry-content><p>Containers aren’t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:
+<a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class="post-entry tag-entry"><header class=entry-header><h2>Choosing Your Desktop Linux Distribution</h2></header><div class=entry-content><p>Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer....</p></div><footer class=entry-footer>5 min&nbsp;·&nbsp;944 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Choosing Your Desktop Linux Distribution" href=https://privsec.dev/os/choosing-your-desktop-linux-distribution/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>Docker and OCI Hardening</h2></header><div class=entry-content><p>Containers aren’t that new fancy thing anymore, but they were a big deal. And they still are. They are a concrete solution to the following problem:
 - Hey, your software doesn’t work…
 - Sorry, it works on my computer! Can’t help you.
 Whether we like them or not, containers are here to stay. Their expressiveness and semantics allow for an abstraction of the OS dependencies that a software has, the latter being often dynamically linked against certain libraries....</p></div><footer class=entry-footer>19 min&nbsp;·&nbsp;3925 words&nbsp;·&nbsp;Wonderfall</footer><a class=entry-link aria-label="post link to Docker and OCI Hardening" href=https://privsec.dev/os/docker-and-oci-hardening/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>F-Droid Security Analysis</h2></header><div class=entry-content><p>F-Droid is a popular alternative app repository for Android, especially known for its main repository dedicated to free and open-source software. F-Droid is often recommended among security and privacy enthusiasts, but how does it stack up against Play Store in practice? This write-up will attempt to emphasize major security issues with F-Droid that you should consider.
 Before we start, a few things to keep in mind:
 The main goal of this write-up was to inform users so they can make responsible choices, not to trash someone else’s work....</p></div><footer class=entry-footer>25 min&nbsp;·&nbsp;5298 words&nbsp;·&nbsp;Wonderfall</footer><a class=entry-link aria-label="post link to F-Droid Security Analysis" href=https://privsec.dev/apps/f-droid-security-analysis/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>Linux Insecurities</h2></header><div class=entry-content><p>There is a common misconception among privacy communities that Linux is one of the more secure operating systems, either because it is open source or because it is widely used in the cloud. This is however, a far cry from reality.
-There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post....</p></div><footer class=entry-footer>1 min&nbsp;·&nbsp;86 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Linux Insecurities" href=https://privsec.dev/os/linux-insecurities/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>Multi-factor Authentication</h2></header><div class=entry-content><p>Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.
-Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification....</p></div><footer class=entry-footer>6 min&nbsp;·&nbsp;1225 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Multi-factor Authentication" href=https://privsec.dev/knowledge/multi-factor-authentication/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>Securing OpenSSH with FIDO2</h2></header><div class=entry-content><p>Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they’re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They’re also easier to manage while enabling a form of decentralized authentication (it’s easy and painless to revoke them). So, what’s the next step? And more exactly, why would one need something even better?
-Why? The main problem with SSH keys is that they’re not magic: they consist of a key pair, of which the private key is stored on your disk....</p></div><footer class=entry-footer>5 min&nbsp;·&nbsp;863 words&nbsp;·&nbsp;Wonderfall</footer><a class=entry-link aria-label="post link to Securing OpenSSH with FIDO2" href=https://privsec.dev/os/securing-openssh-with-fido2/></a></article></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+There is already a very indepth technical blog explaning the various security weaknesses of Linux by Madaidan, Whonix’s Security Researcher. This page will attempt to address some of the questions commonly raised in reaction to his blog post....</p></div><footer class=entry-footer>2 min&nbsp;·&nbsp;238 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Linux Insecurities" href=https://privsec.dev/os/linux-insecurities/></a></article><article class="post-entry tag-entry"><header class=entry-header><h2>Multi-factor Authentication</h2></header><div class=entry-content><p>Multi-factor authentication is a security mechanism that requires additional verification beyond your username (or email) and password. This usually comes in the form of a one time passcode, a push notification, or plugging in and tapping a hardware security key.
+Common protocols Email and SMS MFA Email and SMS MFA are examples of the weaker MFA protocols. Email MFA is not great as whoever controls your email account can typically both reset your password and recieve your MFA verification....</p></div><footer class=entry-footer>6 min&nbsp;·&nbsp;1223 words&nbsp;·&nbsp;Tommy</footer><a class=entry-link aria-label="post link to Multi-factor Authentication" href=https://privsec.dev/knowledge/multi-factor-authentication/></a></article><footer class=page-footer><nav class=pagination><a class=next href=https://privsec.dev/tags/security/page/2/>Next »</a></nav></footer></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
 <span>Powered by
 <a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
         <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script></body></html>
\ No newline at end of file
diff --git a/public/tags/security/index.xml b/public/tags/security/index.xml
index 79fe68a..f70e1f0 100644
--- a/public/tags/security/index.xml
+++ b/public/tags/security/index.xml
@@ -5,6 +5,17 @@
     <link>https://privsec.dev/tags/security/</link>
     <description>Recent content in security on PrivSec.dev</description>
     <generator>Hugo -- gohugo.io</generator><atom:link href="https://privsec.dev/tags/security/index.xml" rel="self" type="application/rss+xml" />
+    <item>
+      <title>Choosing Your Desktop Linux Distribution</title>
+      <link>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</link>
+      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
+      
+      <guid>https://privsec.dev/os/choosing-your-desktop-linux-distribution/</guid>
+      <description>Not all Linux distributions are created equal. When choosing a Linux distribution, there are several things you need to keep in mind.
+Release cycle You should choose a distribution which stays close to the stable upstream software releases, typically rolling release distributions. This is because frozen release cycle distributions often don’t update package versions and fall behind on security updates.
+For frozen distributions, package maintainers are expected to backport patches to fix vulnerabilities (Debian is one such example) rather than bump the software to the “next version” released by the upstream developer.</description>
+    </item>
+    
     <item>
       <title>Docker and OCI Hardening</title>
       <link>https://privsec.dev/os/docker-and-oci-hardening/</link>
diff --git a/public/tags/security/page/2/index.html b/public/tags/security/page/2/index.html
new file mode 100644
index 0000000..1817e77
--- /dev/null
+++ b/public/tags/security/page/2/index.html
@@ -0,0 +1,6 @@
+<!doctype html><html lang=en dir=auto><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=robots content="index, follow"><title>security | PrivSec.dev</title><meta name=keywords content><meta name=description content><meta name=author content="PrivSec Team"><link rel=canonical href=https://privsec.dev/tags/security/><link crossorigin=anonymous href=/assets/css/stylesheet.8b523f1730c922e314350296d83fd666efa16519ca136320a93df674d00b6325.css integrity="sha256-i1I/FzDJIuMUNQKW2D/WZu+hZRnKE2MgqT32dNALYyU=" rel="preload stylesheet" as=style><link rel=icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=16x16 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=icon type=image/png sizes=32x32 href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=apple-touch-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><link rel=mask-icon href=https://privsec.dev/%3Clink%20/%20abs%20url%3E><meta name=theme-color content="#2e2e33"><meta name=msapplication-TileColor content="#2e2e33"><link rel=alternate type=application/rss+xml href=https://privsec.dev/tags/security/index.xml><noscript><style>#theme-toggle,.top-link{display:none}</style></noscript><meta property="og:title" content="security"><meta property="og:description" content><meta property="og:type" content="website"><meta property="og:url" content="https://privsec.dev/tags/security/"><meta name=twitter:card content="summary"><meta name=twitter:title content="security"><meta name=twitter:description content></head><body class="list dark" id=top><script>localStorage.getItem("pref-theme")==="light"&&document.body.classList.remove("dark")</script><header class=header><nav class=nav><div class=logo><a href=https://privsec.dev accesskey=h title="PrivSec.dev (Alt + H)">PrivSec.dev</a><div class=logo-switches><button id=theme-toggle accesskey=t title="(Alt + T)"><svg id="moon" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M21 12.79A9 9 0 1111.21 3 7 7 0 0021 12.79z"/></svg><svg id="sun" xmlns="http://www.w3.org/2000/svg" width="24" height="18" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="5"/><line x1="12" y1="1" x2="12" y2="3"/><line x1="12" y1="21" x2="12" y2="23"/><line x1="4.22" y1="4.22" x2="5.64" y2="5.64"/><line x1="18.36" y1="18.36" x2="19.78" y2="19.78"/><line x1="1" y1="12" x2="3" y2="12"/><line x1="21" y1="12" x2="23" y2="12"/><line x1="4.22" y1="19.78" x2="5.64" y2="18.36"/><line x1="18.36" y1="5.64" x2="19.78" y2="4.22"/></svg></button></div></div><ul id=menu><li><a href=https://privsec.dev/knowledge/ title="Knowledge Base"><span>Knowledge Base</span></a></li><li><a href=https://privsec.dev/os/ title="Operating Systems"><span>Operating Systems</span></a></li><li><a href=https://privsec.dev/apps/ title=Applications><span>Applications</span></a></li><li><a href=https://privsec.dev/providers/ title=Providers><span>Providers</span></a></li></ul></nav></header><main class=main><header class=page-header><div class=breadcrumbs><a href=https://privsec.dev>Home</a>&nbsp;»&nbsp;<a href=https://privsec.dev/tags/>Tags</a></div><h1>security
+<a href=index.xml title=RSS aria-label=RSS><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentcolor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" height="23"><path d="M4 11a9 9 0 019 9"/><path d="M4 4a16 16 0 0116 16"/><circle cx="5" cy="19" r="1"/></svg></a></h1></header><article class="post-entry tag-entry"><header class=entry-header><h2>Securing OpenSSH with FIDO2</h2></header><div class=entry-content><p>Passwordless authentication with OpenSSH keys has been the de facto security standard for years. SSH keys are more robust since they’re cryptographically sane by default, and are therefore resilient to most bruteforce atacks. They’re also easier to manage while enabling a form of decentralized authentication (it’s easy and painless to revoke them). So, what’s the next step? And more exactly, why would one need something even better?
+Why? The main problem with SSH keys is that they’re not magic: they consist of a key pair, of which the private key is stored on your disk....</p></div><footer class=entry-footer>5 min&nbsp;·&nbsp;863 words&nbsp;·&nbsp;Wonderfall</footer><a class=entry-link aria-label="post link to Securing OpenSSH with FIDO2" href=https://privsec.dev/os/securing-openssh-with-fido2/></a></article><footer class=page-footer><nav class=pagination><a class=prev href=https://privsec.dev/tags/security/>« Prev</a></nav></footer></main><footer class=footer><span>&copy; 2022 <a href=https://privsec.dev>PrivSec.dev</a></span>
+<span>Powered by
+<a href=https://gohugo.io/ rel="noopener noreferrer" target=_blank>Hugo</a> &
+        <a href=https://github.com/adityatelange/hugo-PaperMod/ rel=noopener target=_blank>PaperMod</a></span></footer><a href=#top aria-label="go to top" title="Go to Top (Alt + G)" class=top-link id=top-link accesskey=g><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 6" fill="currentcolor"><path d="M12 6H0l6-6z"/></svg></a><script>let menu=document.getElementById("menu");menu&&(menu.scrollLeft=localStorage.getItem("menu-scroll-position"),menu.onscroll=function(){localStorage.setItem("menu-scroll-position",menu.scrollLeft)}),document.querySelectorAll('a[href^="#"]').forEach(e=>{e.addEventListener("click",function(e){e.preventDefault();var t=this.getAttribute("href").substr(1);window.matchMedia("(prefers-reduced-motion: reduce)").matches?document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView():document.querySelector(`[id='${decodeURIComponent(t)}']`).scrollIntoView({behavior:"smooth"}),t==="top"?history.replaceState(null,null," "):history.pushState(null,null,`#${t}`)})})</script><script>var mybutton=document.getElementById("top-link");window.onscroll=function(){document.body.scrollTop>800||document.documentElement.scrollTop>800?(mybutton.style.visibility="visible",mybutton.style.opacity="1"):(mybutton.style.visibility="hidden",mybutton.style.opacity="0")}</script><script>document.getElementById("theme-toggle").addEventListener("click",()=>{document.body.className.includes("dark")?(document.body.classList.remove("dark"),localStorage.setItem("pref-theme","light")):(document.body.classList.add("dark"),localStorage.setItem("pref-theme","dark"))})</script></body></html>
\ No newline at end of file