Recent changes to this wiki. Not to be confused with my history.

Complete source to the wiki is available on gitweb or by cloning this site.

Added a comment: Source Code?
diff --git a/blog/2015-10-20-smartrg-sr630n-proprietary-router-running-linux/comment_9_6d8226905e4fd7bd906d59fa1e19fa1b._comment b/blog/2015-10-20-smartrg-sr630n-proprietary-router-running-linux/comment_9_6d8226905e4fd7bd906d59fa1e19fa1b._comment
new file mode 100644
index 0000000..df86aa3
--- /dev/null
+++ b/blog/2015-10-20-smartrg-sr630n-proprietary-router-running-linux/comment_9_6d8226905e4fd7bd906d59fa1e19fa1b._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ ip="184.175.4.67"
+ claimedauthor="cfriedt"
+ url="http://perpetual-notion.blogspot.com"
+ subject="Source Code?"
+ date="2017-03-25T21:33:40Z"
+ content="""
+Hi,
+
+Has anyone been successful in obtaining the GPL source code for any particular firmware image for this device?
+
+In my case, I'm using the following firmware version
+
+Build Timestamp:	160513_1721
+Software Version:	2.5.0.11
+
+of which I have identified (at minimum) the following GPL software components without published source code:
+* Linux version 2.6.30 (root@cpebuild.smartrg.local) (gcc version 4.4.2 (Buildroot 2010.02-git) ) #1 SMP PREEMPT Fri May 13 17:20:03 PDT 2016
+* BusyBox v1.17.2 (2016-05-13 17:24:35 PDT) multi-call binary.
+Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko
+and others. Licensed under GPLv2.
+* iptables v1.4.0
+
+There are likely many, many more GPL products contained in each firmware image.
+
+I've made the request to SmartRG and received an automated reply but nothing concrete.
+
+From my understanding, it's actually the ISP who is legally responsible for supplying customers with the GPL source code for this device, because they end up selling the products. It seems as though SmartRG may use this caveat as a sort of stalling tactic, as it seems they have avoided supplying any source code for their products at all.
+
+This thread apparently lists the email address of a SmartRG employee who likely can get access to the Linux kernel source code.
+
+http://lists.genieacs.com/pipermail/users/2015-January/000016.html
+
+I, for one, am quite worried that there are likely thousands of security vulnerabilities embedded in these devices due to the sheer age of the linux kernel version.
+
+If anyone is interested in obtaining the source code for their SmartRG product and sees this thread, please take a moment to to list your
+
+Board ID / Build Timestamp / Software Version / ISP / GPL Source Requested
+
+in the replies. E.g.
+
+963168MBV_17AZZ / 160513_1721 / 2.5.0.11 / TekSavvy / Linux 2.6.30, busybox v1.17.2, iptables v1.4.0
+
+I'd be happy to include your information in my dialogue with SmartRG. Hopefully doing so also preempts them to publish _ALL_ of their GPL source code.
+
+
+"""]]

fix broken links
diff --git a/software/debian-development.mdwn b/software/debian-development.mdwn
index 62da233..aab2d6b 100644
--- a/software/debian-development.mdwn
+++ b/software/debian-development.mdwn
@@ -617,10 +617,12 @@ directory. This allows you to share files between the host and the VM,
 and allow for files to "stick" when destroying the VM. This is
 synchronized using [vagrant rsync][], see
 the [official Debian baseboxes documentation][] for more
-information."""]]
+information.
 
 [official Debian baseboxes documentation]: https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes
 [vagrant rsync]: https://docs.vagrantup.com/v2/synced-folders/rsync.html
+"""]]
+
 [other provisionning tools]: https://www.vagrantup.com/docs/provisioning/
 [Puppet]: https://www.vagrantup.com/docs/provisioning/puppet_apply.html
 [Ansible]: https://www.vagrantup.com/docs/provisioning/ansible.html

more links to the official docs
diff --git a/software/debian-development.mdwn b/software/debian-development.mdwn
index 1aa1a60..62da233 100644
--- a/software/debian-development.mdwn
+++ b/software/debian-development.mdwn
@@ -614,21 +614,26 @@ actually remove all data associated with the VM.
 [[!tip """Note that the directory where the VagrantFile is store is,
 by default, shared with the virtual machine, in the `/vagrant`
 directory. This allows you to share files between the host and the VM,
-and allow for files to "stick" when destroying the VM."""]]
+and allow for files to "stick" when destroying the VM. This is
+synchronized using [vagrant rsync][], see
+the [official Debian baseboxes documentation][] for more
+information."""]]
 
+[official Debian baseboxes documentation]: https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes
+[vagrant rsync]: https://docs.vagrantup.com/v2/synced-folders/rsync.html
 [other provisionning tools]: https://www.vagrantup.com/docs/provisioning/
 [Puppet]: https://www.vagrantup.com/docs/provisioning/puppet_apply.html
 [Ansible]: https://www.vagrantup.com/docs/provisioning/ansible.html
 [shell commands]: https://www.vagrantup.com/docs/provisioning/shell.html
 [Vagrantfile]: https://www.vagrantup.com/docs/vagrantfile/
 
-If the [official Vagrant images][] are not up to your taste, you
+If the [official Debian images][] are not up to your taste, you
 can [build your own][] or choose another one from
 the [Hashicorp Atlas][].
 
 [Hashicorp Atlas]: https://atlas.hashicorp.com/boxes/search
 [build your own]: https://wiki.debian.org/Teams/Cloud/RebuildVagrantBaseBoxes
-[official Vagrant images]: https://atlas.hashicorp.com/debian
+[official Debian images]: https://atlas.hashicorp.com/debian
 
 Qemu virtual machines
 ---------------------

add vagrant instructions
diff --git a/software/debian-development.mdwn b/software/debian-development.mdwn
index 0ff14c0..1aa1a60 100644
--- a/software/debian-development.mdwn
+++ b/software/debian-development.mdwn
@@ -572,6 +572,67 @@ distribution. For this, you can use the [debootstrap][] and [chroot][]
 commands. But it is probably better to run tests within a completely
 isolated environment, often called a "Virtual Machine".
 
+There are a *lot* of different virtualization solutions you can use
+([Xen][], [KVM][], [Docker][] and [Virtualbox][]), which are for now
+considered to be outside the scope of this tutorial. I have also
+found [libguestfs][] to be useful to operate on virtual images in
+various ways. [Libvirt][] and [Vagrant][] are also useful wrappers on
+top of the above systems.
+
+[Vagrant]: https://www.vagrantup.com/
+[Virtualbox]: https://en.wikipedia.org/wiki/Virtualbox
+[libguestfs]: https://en.wikipedia.org/wiki/Libguestfs
+[Libvirt]: https://en.wikipedia.org/wiki/Libvirt
+[Docker]: https://en.wikipedia.org/wiki/Docker_(software)
+[Xen]: https://en.wikipedia.org/wiki/Xen
+[HVM]: https://en.wikipedia.org/wiki/Hardware-assisted_virtualization
+[KVM]: https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
+[QCOW]: https://en.wikipedia.org/wiki/Qcow
+[Qemu]: http://qemu.org/
+[chroot]: https://manpages.debian.org/?query=chroot
+
+Vagrant virtual machines
+------------------------
+
+Hashicorp's [Vagrant][] is a useful shortcut you can use to build
+virtual machines consistently. You can get started by using the
+following commands to get SSH into a Wheezy machine, for example:
+
+    sudo apt install vagrant
+    mkdir wheezy64; cd wheezy64
+    vagrant init debian/wheezy64
+    vagrant up
+    vagrant ssh
+
+And that's it. `vagrant init` creates a [Vagrantfile][] that basically
+describes how `vagrant up` can recreate the VM. You can
+use [shell commands][], [Ansible][], [Puppet][]
+or [other provisionning tools][] to automatically configure the VM, of
+course. Use `vagrant halt` to stop the VM and `vagrant destroy` to
+actually remove all data associated with the VM.
+
+[[!tip """Note that the directory where the VagrantFile is store is,
+by default, shared with the virtual machine, in the `/vagrant`
+directory. This allows you to share files between the host and the VM,
+and allow for files to "stick" when destroying the VM."""]]
+
+[other provisionning tools]: https://www.vagrantup.com/docs/provisioning/
+[Puppet]: https://www.vagrantup.com/docs/provisioning/puppet_apply.html
+[Ansible]: https://www.vagrantup.com/docs/provisioning/ansible.html
+[shell commands]: https://www.vagrantup.com/docs/provisioning/shell.html
+[Vagrantfile]: https://www.vagrantup.com/docs/vagrantfile/
+
+If the [official Vagrant images][] are not up to your taste, you
+can [build your own][] or choose another one from
+the [Hashicorp Atlas][].
+
+[Hashicorp Atlas]: https://atlas.hashicorp.com/boxes/search
+[build your own]: https://wiki.debian.org/Teams/Cloud/RebuildVagrantBaseBoxes
+[official Vagrant images]: https://atlas.hashicorp.com/debian
+
+Qemu virtual machines
+---------------------
+
 For now, we will stick with the simplest approach which is using
 [Qemu][]. We will need to use a special tool to create the virtual
 machine as debootstrap only creates a chroot, which virtual machines
@@ -675,23 +736,6 @@ different mountpoint. Otherwise changes in the filesystem affect the
 parent host, in which case you can just copy over the chroot.
 """]]
 
-There are a *lot* of different virtualization solutions you can use
-([Xen][], [KVM][], [Docker][], [Virtualbox][] and [Libvirt][] which
-abstracts some of those away), which are for now considered to be
-outside the scope of this tutorial. I have also found [libguestfs][]
-to be useful to operate on virtual images in various ways.
-
-[Virtualbox]: https://en.wikipedia.org/wiki/Virtualbox
-[libguestfs]: https://en.wikipedia.org/wiki/Libguestfs
-[Libvirt]: https://en.wikipedia.org/wiki/Libvirt
-[Docker]: https://en.wikipedia.org/wiki/Docker_(software)
-[Xen]: https://en.wikipedia.org/wiki/Xen
-[HVM]: https://en.wikipedia.org/wiki/Hardware-assisted_virtualization
-[KVM]: https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
-[QCOW]: https://en.wikipedia.org/wiki/Qcow
-[Qemu]: http://qemu.org/
-[chroot]: https://manpages.debian.org/?query=chroot
-
 Uploading packages
 ==================
 

creating tag page tag/copyright
diff --git a/tag/copyright.mdwn b/tag/copyright.mdwn
new file mode 100644
index 0000000..ccce703
--- /dev/null
+++ b/tag/copyright.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged copyright"]]
+
+[[!inline pages="tagged(copyright)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/github
diff --git a/tag/github.mdwn b/tag/github.mdwn
new file mode 100644
index 0000000..831b39d
--- /dev/null
+++ b/tag/github.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged github"]]
+
+[[!inline pages="tagged(github)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/legal
diff --git a/tag/legal.mdwn b/tag/legal.mdwn
new file mode 100644
index 0000000..df5b28a
--- /dev/null
+++ b/tag/legal.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged legal"]]
+
+[[!inline pages="tagged(legal)" actions="no" archive="yes"
+feedshow=10]]

fix formatting, add tags and original links
diff --git a/blog/2017-03-22-github-tos-update.mdwn b/blog/2017-03-22-github-tos-update.mdwn
new file mode 100644
index 0000000..0ca1b6b
--- /dev/null
+++ b/blog/2017-03-22-github-tos-update.mdwn
@@ -0,0 +1,247 @@
+[[!meta title="An update to GitHub's terms of service"]]
+[[!meta date="2017-03-08T12:00:00-0500"]]
+[[!meta updated="2017-03-22T14:28:41-0400"]]
+
+[[!toc startlevel=2]]
+
+On February 28th, GitHub
+[published](https://github.com/blog/2327-new-github-terms-of-service-are-in-effect)
+a brand new version of its [Terms of
+Service](https://help.github.com/articles/github-terms-of-service/)
+(ToS). While the [first
+draft](https://github.com/blog/2314-new-github-terms-of-service)
+announced earlier in February didn't generate much reaction, the new ToS
+raised concerns that they may break at least the spirit, if not the
+letter, of certain free-software licenses. Digging in further reveals
+that the situation is probably not as dire as some had feared.
+
+The first person to raise the alarm was probably Thorsten Glaser, a
+Debian developer, who
+[stated](http://web.archive.org/web/20170307170233/https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm)
+that the "*new GitHub Terms of Service require removing many Open
+Source works from it*". His concerns are mainly about [section
+D](https://help.github.com/articles/github-terms-of-service/#d-user-generated-content)
+of the document, in particular [section
+D.4](https://help.github.com/articles/github-terms-of-service/#4-license-grant-to-us)
+which states:
+
+> You grant us and our legal successors the right to store and display
+> your Content and make incidental copies as necessary to render the
+> Website and provide the Service.
+
+[Section
+D.5](https://help.github.com/articles/github-terms-of-service/#5-license-grant-to-other-users)
+then goes on to say:
+
+> \[...\] You grant each User of GitHub a nonexclusive, worldwide
+> license to access your Content through the GitHub Service, and to use,
+> display and perform your Content, and to reproduce your Content solely
+> on GitHub as permitted through GitHub's functionality
+
+#### ToS versus GPL
+
+The concern here is that the ToS bypass the normal provisions of
+licenses like the GPL. Indeed, copyleft licenses are based on copyright
+law which forbid users from doing anything with the content unless they
+comply with the license, which forces, among other things, "share alike"
+properties. By granting GitHub and its users rights to reproduce content
+without explicitly respecting the original license, the ToS may allow
+users to bypass the copyleft nature of the license. Indeed, as Joey
+Hess, author of git-annex,
+[explained](http://joeyh.name/blog/entry/removing_everything_from_github/)
+:
+
+> The new TOS is potentially very bad for copylefted Free Software. It
+> potentially neuters it entirely, so GPL licensed software hosted on
+> Github has an implicit BSD-like license
+
+Hess has since removed all his content (mostly mirrors) from GitHub.
+
+Others disagree. In a well-reasoned blog post, Debian developer Jonathan
+McDowell
+[explained](https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html)
+the rationale behind the changes:
+
+> My reading of the GitHub changes is that they are driven by a desire
+> to ensure that GitHub are legally covered for the things they need to
+> do with your code in order to run their service.
+
+This seems like a fair point to make: GitHub needs to protect its own
+rights to operate the service. McDowell then goes on to do a detailed
+rebuttal of the arguments made by Glaser, arguing specifically that
+section D.5 "*does not grant \[...\] additional rights to reproduce
+outside of GitHub*".
+
+However, specific problems arise when we consider that GitHub is a
+private corporation that users have no control over. The "Services"
+defined in the ToS explicitly "*refers to the applications,
+software, products, and services provided by GitHub*". The term
+"Services" is therefore not limited to the current set of services. This
+loophole may actually give GitHub the right to bypass certain provisions
+of licenses used on GitHub. As Hess detailed in a [later blog
+post](http://joeyh.name/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS/):
+
+> If Github tomorrow starts providing say, an App Store service, that
+> necessarily involves distribution of software to others, and they put
+> my software in it, would that be allowed by this or not?
+>
+> If that hypothetical Github App Store doesn't sell apps, but licenses
+> access to them for money, would that be allowed under this license
+> that they want to my software?
+
+However, when asked on IRC, Bradley M. Kuhn of the Software Freedom
+Conservancy explained that "ultimately, failure to comply with a
+copyleft license is a copyright infringement" and that the ToS do
+outline a process to deal with such infringement. Some lawyers have also
+publicly expressed their disagreement with Glaser's assessment, with
+Richard Fontana from Red Hat
+[saying](https://twitter.com/richardfontana/status/837370085392199681)
+that the analysis is "*basically wrong*". It all comes down
+to the intent of the ToS, as Kuhn (who is not a lawyer) explained:
+
+> *any* license can be abused or misused for an intent other than its
+> original intent. It's why it matters to get every little detail right,
+> and I hope Github will do that.
+
+He went even further and said that "we should assume the ambiguity in
+their ToS as it stands is favorable to Free Software".
+
+The ToS are in effect since February 28th; users "*can accept them
+by clicking the broadcast announcement on your dashboard or by
+continuing to use GitHub*". The immediacy of the change is one of
+the reasons why certain people are rushing to remove content from
+GitHub: there are concerns that continuing to use the service may be
+interpreted as consent to bypass those licenses. Hess even hosted a
+[separate copy of the ToS
+\[PDF\]](https://tmp.joeyh.name/github-tos.pdf) for people to be able to
+read the document without implicitly consenting. It is, however, unclear
+how a user should remove their content from the GitHub servers without
+actually agreeing to the new ToS.
+
+#### CLAs
+
+When I read the first draft, I initially thought there would be concerns
+about the mandatory Contributor License Agreement (CLA) in [section D.5
+of the
+draft](https://help.github.com/articles/github-terms-of-service-draft/#5-license-grant-to-other-users):
+
+> \[...\] unless there is a Contributor License Agreement to the
+> contrary, whenever you make a contribution to a repository containing
+> notice of a license, you license your contribution under the same
+> terms, and agree that you have the right to license your contribution
+> under those terms.
+
+I was concerned this would establish the controversial practice of
+forcing CLAs on every GitHub user. I managed to find a post from a
+lawyer, Kyle E. Mitchell, who
+[commented](https://writing.kemitchell.com/2017/02/16/Against-Legislating-the-Nonobvious.html)
+on the draft and, specifically, on the CLA. He outlined issues with
+wording and definition problems in that section of the draft. In
+particular, he noted that "*contributor license agreement is not a
+legal term of art, but an industry term*" and "*is a bit
+fuzzy*". This was clarified in the final draft, in [section
+D.6](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license),
+by removing the use of the CLA term and by explicitly mentioning the
+widely accepted norm for licenses: "inbound=outbound". So it seems that
+section D.6 is not really a problem: contributors do not need to
+necessarily delegate copyright ownership (as some CLAs require) when
+they make a contribution, unless otherwise noted by a
+repository-specific CLA.
+
+An interesting concern he raised, however, was with *how* GitHub
+conducted the drafting process. A blog post announced the change on
+February 7th with a link to a form to provide feedback until the 21st,
+with a publishing deadline of February 28th. This gave little time for
+lawyers and developers to review the document and comment on it. Users
+then had to basically accept whatever came out of the process as-is.
+
+Unlike every software project hosted on GitHub, the ToS document is not
+part of a Git repository people can propose changes to or even
+collaboratively discuss. While Mitchell acknowledges that "*GitHub
+are within their rights to update their terms, within very broad limits,
+more or less however they like, whenever they like*", he sets
+higher standards for GitHub than for other corporations, considering the
+community it serves and the spirit it represents. He described the
+process as:
+
+> \[...\] consistent with the value of CYA, which is real, but not with
+> the output-improving virtues of open process, which is also real, and
+> a great deal more pleasant.
+
+Mitchell also explained that, because of its position, GitHub can have a
+major impact on the free-software world.
+
+> And as the current forum of preference for a great many developers,
+> the knock-on effects of their decisions throw big weight. While GitHub
+> have the wheel—and they’ve certainly earned it for now—they can do
+> real damage.
+
+In particular, there have been some concerns that the ToS change may be
+an attempt to further the already [diminishing
+adoption](https://en.wikipedia.org/wiki/GNU_General_Public_License#Adoption)
+of the GPL for free-software projects; on GitHub, the GPL has been
+[surpassed](https://github.com/blog/1964-license-usage-on-github-com) by
+the MIT license. But Kuhn believes that attitudes at GitHub have begun
+changing:
+
+> GitHub historically had an anti-copyleft culture, which was created in
+> large part by their former and now ousted CEO, Preston-Warner.
+> However, recently, I've seen people at GitHub truly reach out to me
+> and others in the copyleft community to learn more and open their
+> minds. I thus have a hard time believing that there was some
+> anti-copyleft conspiracy in this ToS change.
+
+#### GitHub response

(Diff truncated)
Merge branch 'new'
Conflicts:
sigs.fortune
add pratchett quote
diff --git a/sigs.fortune b/sigs.fortune
index 084f758..6cbf73f 100644
--- a/sigs.fortune
+++ b/sigs.fortune
@@ -1009,5 +1009,7 @@ We won't have a society if we destroy the environment.
 What people say, what people do, and what they say they do are
 entirely different things.
                         - Margaret Mead
-
-
+%
+Gods don't like people not doing much work. People who aren't busy all
+the time might start to think.
+                        - Terry Pratchett, Small Gods

fixup bkuhn quote after approval
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index f52284a..c92640f 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -184,11 +184,11 @@ of the GPL for free-software projects; on GitHub, the GPL has been
 the MIT license. But Kuhn believes that attitudes at GitHub have begun
 changing:
 
-> Github historically had an anti-copyleft culture, which was created in
-> large \[part\] by their former and now ousted CEO, Preston-Warner.
-> \[...\] Given that I've seen people at Github truly reach out to me
+> GitHub historically had an anti-copyleft culture, which was created in
+> large part by their former and now ousted CEO, Preston-Warner.
+> However, recently, I've seen people at GitHub truly reach out to me
 > and others in the copyleft community to learn more and open their
-> minds, I have a \[...\] hard time believing that there was some
+> minds. I thus have a hard time believing that there was some
 > anti-copyleft conspiracy in this ToS change.
 
 #### GitHub response

integrate warning header, it should disappear when we can publish the article anyways
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index cb885e6..f52284a 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -1,6 +1,9 @@
 An update to GitHub's terms of service
 ======================================
 
+\[LWN subscriber-only content\]
+-------------------------------
+
 On February 28th, GitHub
 [published](https://github.com/blog/2327-new-github-terms-of-service-are-in-effect)
 a brand new version of its [Terms of
@@ -234,3 +237,4 @@ especially for end users who generally click through without reading
 them. We should probably applaud the efforts made by GitHub to make its
 own ToS document more readable and hope that, with time, it will address
 the community's concerns.
+

reimport from LWN
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index 9b09ccd..cb885e6 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -137,7 +137,7 @@ wording and definition problems in that section of the draft. In
 particular, he noted that "<span>contributor license agreement is not a
 legal term of art, but an industry term</span>" and "<span>is a bit
 fuzzy</span>". This was clarified in the final draft, in [section
-D.6](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license)
+D.6](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license),
 by removing the use of the CLA term and by explicitly mentioning the
 widely accepted norm for licenses: "inbound=outbound". So it seems that
 section D.6 is not really a problem: contributors do not need to
@@ -166,7 +166,7 @@ process as:
 > a great deal more pleasant.
 
 Mitchell also explained that, because of its position, GitHub can have a
-major impact on the free-software world:
+major impact on the free-software world.
 
 > And as the current forum of preference for a great many developers,
 > the knock-on effects of their decisions throw big weight. While GitHub
@@ -178,15 +178,15 @@ an attempt to further the already [diminishing
 adoption](https://en.wikipedia.org/wiki/GNU_General_Public_License#Adoption)
 of the GPL for free-software projects; on GitHub, the GPL has been
 [surpassed](https://github.com/blog/1964-license-usage-on-github-com) by
-the MIT license. But, Kuhn believes that has begun changing at the
-company:
+the MIT license. But Kuhn believes that attitudes at GitHub have begun
+changing:
 
 > Github historically had an anti-copyleft culture, which was created in
-> large by their former and now ousted CEO, Preston-Warner. \[...\]
-> Given that I've seen people at Github truly reach out to me and others
-> in the copyleft community to learn more and open their minds, I have a
-> \[...\] hard time believing that there was some anti-copyleft
-> conspiracy in this ToS change.
+> large \[part\] by their former and now ousted CEO, Preston-Warner.
+> \[...\] Given that I've seen people at Github truly reach out to me
+> and others in the copyleft community to learn more and open their
+> minds, I have a \[...\] hard time believing that there was some
+> anti-copyleft conspiracy in this ToS change.
 
 #### GitHub response
 

reconvert using new tools to follow our format already
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index 9e2b36e..9b09ccd 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -1,9 +1,6 @@
-
 An update to GitHub's terms of service
 ======================================
 
-
-
 On February 28th, GitHub
 [published](https://github.com/blog/2327-new-github-terms-of-service-are-in-effect)
 a brand new version of its [Terms of
@@ -25,26 +22,18 @@ of the document, in particular [section
 D.4](https://help.github.com/articles/github-terms-of-service/#4-license-grant-to-us)
 which states:
 
-<div class="BigQuote">
-
-You grant us and our legal successors the right to store and display
-your Content and make incidental copies as necessary to render the
-Website and provide the Service.
-
-</div>
+> You grant us and our legal successors the right to store and display
+> your Content and make incidental copies as necessary to render the
+> Website and provide the Service.
 
 [Section
 D.5](https://help.github.com/articles/github-terms-of-service/#5-license-grant-to-other-users)
 then goes on to say:
 
-<div class="BigQuote">
-
-\[...\] You grant each User of GitHub a nonexclusive, worldwide license
-to access your Content through the GitHub Service, and to use, display
-and perform your Content, and to reproduce your Content solely on GitHub
-as permitted through GitHub's functionality
-
-</div>
+> \[...\] You grant each User of GitHub a nonexclusive, worldwide
+> license to access your Content through the GitHub Service, and to use,
+> display and perform your Content, and to reproduce your Content solely
+> on GitHub as permitted through GitHub's functionality
 
 #### ToS versus GPL
 
@@ -59,13 +48,9 @@ Hess, author of git-annex,
 [explained](http://joeyh.name/blog/entry/removing_everything_from_github/)
 :
 
-<div class="BigQuote">
-
-The new TOS is potentially very bad for copylefted Free Software. It
-potentially neuters it entirely, so GPL licensed software hosted on
-Github has an implicit BSD-like license
-
-</div>
+> The new TOS is potentially very bad for copylefted Free Software. It
+> potentially neuters it entirely, so GPL licensed software hosted on
+> Github has an implicit BSD-like license
 
 Hess has since removed all his content (mostly mirrors) from GitHub.
 
@@ -74,13 +59,9 @@ McDowell
 [explained](https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html)
 the rationale behind the changes:
 
-<div class="BigQuote">
-
-My reading of the GitHub changes is that they are driven by a desire to
-ensure that GitHub are legally covered for the things they need to do
-with your code in order to run their service.
-
-</div>
+> My reading of the GitHub changes is that they are driven by a desire
+> to ensure that GitHub are legally covered for the things they need to
+> do with your code in order to run their service.
 
 This seems like a fair point to make: GitHub needs to protect its own
 rights to operate the service. McDowell then goes on to do a detailed
@@ -97,17 +78,13 @@ loophole may actually give GitHub the right to bypass certain provisions
 of licenses used on GitHub. As Hess detailed in a [later blog
 post](http://joeyh.name/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS/):
 
-<div class="BigQuote">
-
-If Github tomorrow starts providing say, an App Store service, that
-necessarily involves distribution of software to others, and they put my
-software in it, would that be allowed by this or not?
-
-If that hypothetical Github App Store doesn't sell apps, but licenses
-access to them for money, would that be allowed under this license that
-they want to my software?
-
-</div>
+> If Github tomorrow starts providing say, an App Store service, that
+> necessarily involves distribution of software to others, and they put
+> my software in it, would that be allowed by this or not?
+>
+> If that hypothetical Github App Store doesn't sell apps, but licenses
+> access to them for money, would that be allowed under this license
+> that they want to my software?
 
 However, when asked on IRC, Bradley M. Kuhn of the Software Freedom
 Conservancy explained that "ultimately, failure to comply with a
@@ -119,13 +96,9 @@ Richard Fontana from Red Hat
 that the analysis is "<span>basically wrong</span>". It all comes down
 to the intent of the ToS, as Kuhn (who is not a lawyer) explained:
 
-<div class="BigQuote">
-
-*any* license can be abused or misused for an intent other than its
-original intent. It's why it matters to get every little detail right,
-and I hope Github will do that.
-
-</div>
+> *any* license can be abused or misused for an intent other than its
+> original intent. It's why it matters to get every little detail right,
+> and I hope Github will do that.
 
 He went even further and said that "we should assume the ambiguity in
 their ToS as it stands is favorable to Free Software".
@@ -149,14 +122,11 @@ about the mandatory Contributor License Agreement (CLA) in [section D.5
 of the
 draft](https://help.github.com/articles/github-terms-of-service-draft/#5-license-grant-to-other-users):
 
-<div class="BigQuote">
-
-\[...\] unless there is a Contributor License Agreement to the contrary,
-whenever you make a contribution to a repository containing notice of a
-license, you license your contribution under the same terms, and agree
-that you have the right to license your contribution under those terms.
-
-</div>
+> \[...\] unless there is a Contributor License Agreement to the
+> contrary, whenever you make a contribution to a repository containing
+> notice of a license, you license your contribution under the same
+> terms, and agree that you have the right to license your contribution
+> under those terms.
 
 I was concerned this would establish the controversial practice of
 forcing CLAs on every GitHub user. I managed to find a post from a
@@ -191,39 +161,31 @@ higher standards for GitHub than for other corporations, considering the
 community it serves and the spirit it represents. He described the
 process as:
 
-<div class="BigQuote">
-
-\[...\] consistent with the value of CYA, which is real, but not with
-the output-improving virtues of open process, which is also real, and a
-great deal more pleasant.
+> \[...\] consistent with the value of CYA, which is real, but not with
+> the output-improving virtues of open process, which is also real, and
+> a great deal more pleasant.
 
-</div>
+Mitchell also explained that, because of its position, GitHub can have a
+major impact on the free-software world:
 
-Mitchell also explained that, because of its position, GitHub can have
-a major impact on the free-software world:
+> And as the current forum of preference for a great many developers,
+> the knock-on effects of their decisions throw big weight. While GitHub
+> have the wheel—and they’ve certainly earned it for now—they can do
+> real damage.
 
-<div class="BigQuote">
-
-And as the current forum of preference for a great many developers, the
-knock-on effects of their decisions throw big weight. While GitHub have
-the wheel—and they’ve certainly earned it for now—they can do real
-damage.
-
-</div>
-
-In particular, there have been some concerns that the ToS change may be an
-attempt to further the already [diminishing
+In particular, there have been some concerns that the ToS change may be
+an attempt to further the already [diminishing
 adoption](https://en.wikipedia.org/wiki/GNU_General_Public_License#Adoption)
 of the GPL for free-software projects; on GitHub, the GPL has been
 [surpassed](https://github.com/blog/1964-license-usage-on-github-com) by
 the MIT license. But, Kuhn believes that has begun changing at the
 company:
 
-> Github historically had an anti-copyleft culture, which was created
-> in large by their former and now ousted CEO, Preston-Warner. [...]
-> Given that I've seen people at Github truly reach out to me and
-> others in the copyleft community to learn more and open their minds,
-> I have a [...] hard time believing that there was some anti-copyleft
+> Github historically had an anti-copyleft culture, which was created in
+> large by their former and now ousted CEO, Preston-Warner. \[...\]
+> Given that I've seen people at Github truly reach out to me and others
+> in the copyleft community to learn more and open their minds, I have a
+> \[...\] hard time believing that there was some anti-copyleft
 > conspiracy in this ToS change.
 
 #### GitHub response

(Diff truncated)
add some haskell in there
diff --git a/software/mytasks.desc b/software/mytasks.desc
index af189d0..28fef26 100644
--- a/software/mytasks.desc
+++ b/software/mytasks.desc
@@ -43,6 +43,8 @@ Packages: list
  golang-mode
  golint
  graphviz
+ haskell-mode
+ stylish-haskell
  ikiwiki
  info
  jq

bring in the quote from Kuhn and reorder to not attribute the MIT conspiracy on mitchell
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index dcb7c2b..9e2b36e 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -199,13 +199,8 @@ great deal more pleasant.
 
 </div>
 
-Furthermore, there have been some concerns that the ToS change may be an
-attempt to further the already [diminishing
-adoption](https://en.wikipedia.org/wiki/GNU_General_Public_License#Adoption)
-of the GPL for free-software projects; on GitHub, the GPL has been
-[surpassed](https://github.com/blog/1964-license-usage-on-github-com) by
-the MIT license. Because of its position, GitHub can have a major impact
-on the free-software world. As Mitchell described:
+Mitchell also explained that, because of its position, GitHub can have
+a major impact on the free-software world:
 
 <div class="BigQuote">
 
@@ -216,9 +211,20 @@ damage.
 
 </div>
 
-But, while acknowledging some anti-GPL sentiment at GitHub in the past,
-Kuhn believes that has begun changing at the company. He does not see
-the ToS change as something that is license-choice related.
+In particular, there have been some concerns that the ToS change may be an
+attempt to further the already [diminishing
+adoption](https://en.wikipedia.org/wiki/GNU_General_Public_License#Adoption)
+of the GPL for free-software projects; on GitHub, the GPL has been
+[surpassed](https://github.com/blog/1964-license-usage-on-github-com) by
+the MIT license. But, Kuhn believes that has begun changing at the
+company:
+
+> Github historically had an anti-copyleft culture, which was created
+> in large by their former and now ousted CEO, Preston-Warner. [...]
+> Given that I've seen people at Github truly reach out to me and
+> others in the copyleft community to learn more and open their minds,
+> I have a [...] hard time believing that there was some anti-copyleft
+> conspiracy in this ToS change.
 
 #### GitHub response
 

reimport from lwn
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index 030b723..dcb7c2b 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -1,6 +1,9 @@
+
 An update to GitHub's terms of service
 ======================================
 
+
+
 On February 28th, GitHub
 [published](https://github.com/blog/2327-new-github-terms-of-service-are-in-effect)
 a brand new version of its [Terms of
@@ -196,14 +199,13 @@ great deal more pleasant.
 
 </div>
 
-Furthermore, there are concerns that the ToS change may be an attempt to
-further the already [diminishing
+Furthermore, there have been some concerns that the ToS change may be an
+attempt to further the already [diminishing
 adoption](https://en.wikipedia.org/wiki/GNU_General_Public_License#Adoption)
-of the GPL for free-software projects; the GPL has been
+of the GPL for free-software projects; on GitHub, the GPL has been
 [surpassed](https://github.com/blog/1964-license-usage-on-github-com) by
-the MIT license on GitHub. By formalizing this change in its ToS, GitHub
-could have a major impact on the free-software world. As Mitchell
-described:
+the MIT license. Because of its position, GitHub can have a major impact
+on the free-software world. As Mitchell described:
 
 <div class="BigQuote">
 
@@ -214,6 +216,10 @@ damage.
 
 </div>
 
+But, while acknowledging some anti-GPL sentiment at GitHub in the past,
+Kuhn believes that has begun changing at the company. He does not see
+the ToS change as something that is license-choice related.
+
 #### GitHub response
 
 However, it seems that GitHub has actually been proactive in reaching
@@ -264,3 +270,4 @@ especially for end users who generally click through without reading
 them. We should probably applaud the efforts made by GitHub to make its
 own ToS document more readable and hope that, with time, it will address
 the community's concerns.
+

more clarifications from LWN
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index 0064d33..030b723 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -3,21 +3,22 @@ An update to GitHub's terms of service
 
 On February 28th, GitHub
 [published](https://github.com/blog/2327-new-github-terms-of-service-are-in-effect)
-a brand new version of its
-[Terms of Service](https://help.github.com/articles/github-terms-of-service/)
-(ToS). While the
-[first draft](https://github.com/blog/2314-new-github-terms-of-service)
-announced earlier in February didn't generate much reaction, the new
-ToS raised concerns that they may break the spirit, if not the letter,
-of certain free-software licenses.
+a brand new version of its [Terms of
+Service](https://help.github.com/articles/github-terms-of-service/)
+(ToS). While the [first
+draft](https://github.com/blog/2314-new-github-terms-of-service)
+announced earlier in February didn't generate much reaction, the new ToS
+raised concerns that they may break at least the spirit, if not the
+letter, of certain free-software licenses. Digging in further reveals
+that the situation is probably not as dire as some had feared.
 
 The first person to raise the alarm was probably Thorsten Glaser, a
 Debian developer, who
-[suggested](https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm)
+[stated](http://web.archive.org/web/20170307170233/https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm)
 that the "<span>new GitHub Terms of Service require removing many Open
 Source works from it</span>". His concerns are mainly about [section
 D](https://help.github.com/articles/github-terms-of-service/#d-user-generated-content)
-of the document, for example [section
+of the document, in particular [section
 D.4](https://help.github.com/articles/github-terms-of-service/#4-license-grant-to-us)
 which states:
 
@@ -105,11 +106,12 @@ they want to my software?
 
 </div>
 
-However, when asked, Bradley M. Kuhn of the Software Freedom Conservancy
-explained that "ultimately, failure to comply with a copyleft license is
-a copyright infringement" and that the ToS do outline a process to deal
-with such infringement. Some lawyers have also publicly expressed their
-disagreement with Glaser's assessment, with Richard Fontana from Red Hat
+However, when asked on IRC, Bradley M. Kuhn of the Software Freedom
+Conservancy explained that "ultimately, failure to comply with a
+copyleft license is a copyright infringement" and that the ToS do
+outline a process to deal with such infringement. Some lawyers have also
+publicly expressed their disagreement with Glaser's assessment, with
+Richard Fontana from Red Hat
 [saying](https://twitter.com/richardfontana/status/837370085392199681)
 that the analysis is "<span>basically wrong</span>". It all comes down
 to the intent of the ToS, as Kuhn (who is not a lawyer) explained:
@@ -153,21 +155,22 @@ that you have the right to license your contribution under those terms.
 
 </div>
 
-I was concerned this would force the controversial practice of forcing
-CLAs on every GitHub user. I managed to find a post from a lawyer, Kyle
-E. Mitchell, who
+I was concerned this would establish the controversial practice of
+forcing CLAs on every GitHub user. I managed to find a post from a
+lawyer, Kyle E. Mitchell, who
 [commented](https://writing.kemitchell.com/2017/02/16/Against-Legislating-the-Nonobvious.html)
 on the draft and, specifically, on the CLA. He outlined issues with
 wording and definition problems in that section of the draft. In
-particular, he noted that "<span>Contributor license agreement is not a
+particular, he noted that "<span>contributor license agreement is not a
 legal term of art, but an industry term</span>" and "<span>is a bit
 fuzzy</span>". This was clarified in the final draft, in [section
 D.6](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license)
 by removing the use of the CLA term and by explicitly mentioning the
 widely accepted norm for licenses: "inbound=outbound". So it seems that
 section D.6 is not really a problem: contributors do not need to
-necessarily delegate copyright ownership when they make a contribution,
-unless otherwise noted by a repository-specific CLA.
+necessarily delegate copyright ownership (as some CLAs require) when
+they make a contribution, unless otherwise noted by a
+repository-specific CLA.
 
 An interesting concern he raised, however, was with *how* GitHub
 conducted the drafting process. A blog post announced the change on

reorder a sentence
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index 83e0e4d..0064d33 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -3,13 +3,13 @@ An update to GitHub's terms of service
 
 On February 28th, GitHub
 [published](https://github.com/blog/2327-new-github-terms-of-service-are-in-effect)
-a brand new version of its [Terms of
-Service](https://help.github.com/articles/github-terms-of-service/)
-(ToS). While the [first
-draft](https://github.com/blog/2314-new-github-terms-of-service)
-announced earlier in February didn't generate much reaction, the new ToS
-raised concerns that they may break if not the letter, at least the
-spirit of certain free-software licenses.
+a brand new version of its
+[Terms of Service](https://help.github.com/articles/github-terms-of-service/)
+(ToS). While the
+[first draft](https://github.com/blog/2314-new-github-terms-of-service)
+announced earlier in February didn't generate much reaction, the new
+ToS raised concerns that they may break the spirit, if not the letter,
+of certain free-software licenses.
 
 The first person to raise the alarm was probably Thorsten Glaser, a
 Debian developer, who

first batch of reviews from LWN
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index dcbe1ec..83e0e4d 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -1,220 +1,263 @@
-GitHub terms of service update
-==============================
+An update to GitHub's terms of service
+======================================
+
+On February 28th, GitHub
+[published](https://github.com/blog/2327-new-github-terms-of-service-are-in-effect)
+a brand new version of its [Terms of
+Service](https://help.github.com/articles/github-terms-of-service/)
+(ToS). While the [first
+draft](https://github.com/blog/2314-new-github-terms-of-service)
+announced earlier in February didn't generate much reaction, the new ToS
+raised concerns that they may break if not the letter, at least the
+spirit of certain free-software licenses.
 
-On February 28th, GitHub [published][] a brand new version of
-their [Terms of Service][] (ToS). While the [first draft][] announced
-earlier in February didn't generate much pushback, the new change
-raised concerns that the ToS may break if not the letter, at least
-the spirit of certain free software licenses.
+The first person to raise the alarm was probably Thorsten Glaser, a
+Debian developer, who
+[suggested](https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm)
+that the "<span>new GitHub Terms of Service require removing many Open
+Source works from it</span>". His concerns are mainly about [section
+D](https://help.github.com/articles/github-terms-of-service/#d-user-generated-content)
+of the document, for example [section
+D.4](https://help.github.com/articles/github-terms-of-service/#4-license-grant-to-us)
+which states:
 
-[first draft]: https://github.com/blog/2314-new-github-terms-of-service
-[Terms of Service]: https://help.github.com/articles/github-terms-of-service/
-[published]: https://github.com/blog/2327-new-github-terms-of-service-are-in-effect
+<div class="BigQuote">
 
-The first person to raise the alarm was probably Thorsten Glaser, a
-Debian developer, who [announced][] that the "*new GitHub Terms of
-Service require removing many Open Source works from it*". His
-concerns are mainly around [section D][] of the document, for example
-section D.4 which states that:
-
-[announced]: https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm
-
-> You grant us and our legal successors the right to store and display
-> your Content and make incidental copies as necessary to render the
-> Website and provide the Service.
-
-Section D.5 then goes on to state that:
-
-> [...] You grant each User of GitHub a nonexclusive, worldwide
-> license to access your Content through the GitHub Service, and to
-> use, display and perform your Content, and to reproduce your Content
-> solely on GitHub as permitted through GitHub's functionality
-
-The concern here is that the ToS *bypass* the normal provisions of
-licenses like the GPL. Indeed, copyleft licenses are based on
-copyright law which forbid users from doing anything with the content
-unless they comply with the license, which forces, among other things,
-"share alike" properties. By granting GitHub and its users rights to
-reproduce content *without* explicitly respecting the original
-license, the ToS may allow users to bypass the copyleft nature of the
-license. Indeed, as Joey Hess, author of Git-annex,
-[explained](http://joeyh.name/blog/entry/removing_everything_from_github/) :
-
-> The new TOS is potentially very bad for copylefted Free Software. It
-> potentially neuters it entirely, so GPL licensed software hosted on
-> Github has an implicit BSD-like license
+You grant us and our legal successors the right to store and display
+your Content and make incidental copies as necessary to render the
+Website and provide the Service.
+
+</div>
+
+[Section
+D.5](https://help.github.com/articles/github-terms-of-service/#5-license-grant-to-other-users)
+then goes on to say:
+
+<div class="BigQuote">
+
+\[...\] You grant each User of GitHub a nonexclusive, worldwide license
+to access your Content through the GitHub Service, and to use, display
+and perform your Content, and to reproduce your Content solely on GitHub
+as permitted through GitHub's functionality
+
+</div>
+
+#### ToS versus GPL
+
+The concern here is that the ToS bypass the normal provisions of
+licenses like the GPL. Indeed, copyleft licenses are based on copyright
+law which forbid users from doing anything with the content unless they
+comply with the license, which forces, among other things, "share alike"
+properties. By granting GitHub and its users rights to reproduce content
+without explicitly respecting the original license, the ToS may allow
+users to bypass the copyleft nature of the license. Indeed, as Joey
+Hess, author of git-annex,
+[explained](http://joeyh.name/blog/entry/removing_everything_from_github/)
+:
+
+<div class="BigQuote">
+
+The new TOS is potentially very bad for copylefted Free Software. It
+potentially neuters it entirely, so GPL licensed software hosted on
+Github has an implicit BSD-like license
+
+</div>
 
 Hess has since removed all his content (mostly mirrors) from GitHub.
 
-Others disagree. In a well-reasoned blog post, Debian developer
-Jonathan McDowell [explained][] the rationale behind the changes:
+Others disagree. In a well-reasoned blog post, Debian developer Jonathan
+McDowell
+[explained](https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html)
+the rationale behind the changes:
+
+<div class="BigQuote">
 
-[explained]: https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html
+My reading of the GitHub changes is that they are driven by a desire to
+ensure that GitHub are legally covered for the things they need to do
+with your code in order to run their service.
 
-> My reading of the GitHub changes is that they are driven by a desire
-> to ensure that GitHub are legally covered for the things they need
-> to do with your code in order to run their service.
+</div>
 
 This seems like a fair point to make: GitHub needs to protect its own
 rights to operate the service. McDowell then goes on to do a detailed
-rebuttal of the arguments brought by Glaser, arguing specifically that
-section D.5 "*does not grant [...] additional rights to reproduce
-outside of GitHub*".
+rebuttal of the arguments made by Glaser, arguing specifically that
+section D.5 "<span>does not grant \[...\] additional rights to reproduce
+outside of GitHub</span>".
 
 However, specific problems arise when we consider that GitHub is a
-private corporation that users have no control over. The "*Services*"
-defined in the ToS explicitly "*refers to the applications, software,
-products, and services provided by GitHub*". The term "Services" is
-therefore not limited to the current set of services. This loophole
-may actually give GitHub the right to bypass certain provisions of
-licenses used on GitHub. As Hess detailed in a
-[later blog post](http://joeyh.name/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS/):
-
-> If Github tomorrow starts providing say, an App Store service, that
-> necessarily involves distribution of software to others, and they
-> put my software in it, would that be allowed by this or not?
-
-> If that hypothetical Github App Store doesn't sell apps, but
-> licenses access to them for money, would that be allowed under this
-> license that they want to my software?
-
-In an interview, however, Bradley M. Kuhn, of Software Freedom
-Conservancy, explained that "*ultimately, failure to comply with a
-copyleft license is a copyright infringement*" and that the ToS do
-outline a process to deal with such infringement. Some lawyers have
-also publicly expressed their disagreement with Glaser's assessment,
-with
-[Richard Fontana](https://twitter.com/richardfontana/status/837370085392199681) from
-Red Hat saying that the analysis is "*basically wrong*". It all comes
-down to the intent of the ToS, as Kuhn (who is not a lawyer)
-explained:
-
-> *any* license can be abused or misused for an intent other than its
-> original intent. It's why it matters to get every little detail
-> right, and I hope Github will do that.
-
-He went even further and stated that "*we should assume the ambiguity
-in their ToS as it stands is favorable to Free Software*".
-
-The ToS are in effect since February 28th and users "*can accept
-them by clicking the broadcast announcement on your dashboard or by
-continuing to use GitHub*". The immediacy of the change is one of the
-reasons why certain people are rushing to remove content from GitHub:
-there are concerns that their continuous use of the service may be
-interpreted as consent to bypass those licenses. Hess even hosted
-a [separete copy of the ToS][] for people to be able to read the
-document without implicitly consenting. It is, however, unclear how a
-user should remove their content from the GitHub servers without
-actually agreeing with the new ToS.
-
-[separete copy of the ToS]: https://tmp.joeyh.name/github-tos.pdf
-
-When I read the first draft of the ToS, I initially thought there
-would be concerns about the mandatory Contributor's License Agreement
-(CLA, [section D.5 of the draft][]):
-
-> unless there is a Contributor License Agreement to the contrary,
-> whenever you make a contribution to a repository containing notice
-> of a license, you license your contribution under the same terms,
-> and agree that you have the right to license your contribution under
-> those terms
-

(Diff truncated)
revert change re. gh spokesperson
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index a402223..dcbe1ec 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -176,8 +176,8 @@ out to the free software community. Kuhn explained that it actually
 contacted the Conservancy to get their advice on the ToS changes.
 While he still thinks GitHub should fix the ambiguities quickly, he
 also noted that those issues "*impact pretty much any non-trivial Open
-Source and Free Software license*", not just copylefted material. In
-an email interview, GitHub spokesperson stated that:
+Source and Free Software license*", not just copylefted material. When
+reached for comments, a GitHub spokesperson stated that:
 
 > While we are confident that these Terms serve the best needs of the
 > community, we take our users’ feedback very seriously and we are

Added a comment: a password maker 5-minute review...
diff --git a/blog/2017-03-02-password-hashers/comment_2_17920f18b78627307cf3828705c0290e._comment b/blog/2017-03-02-password-hashers/comment_2_17920f18b78627307cf3828705c0290e._comment
new file mode 100644
index 0000000..a7496bb
--- /dev/null
+++ b/blog/2017-03-02-password-hashers/comment_2_17920f18b78627307cf3828705c0290e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="a password maker 5-minute review..."
+ date="2017-03-07T14:54:46Z"
+ content="""
+... is available in [[blog/2017-03-02-hashers-history]].
+
+(sorry your comment was in moderation here, spammers have been so hostile that I've taken rather drastic measures, although I don't exactly know why your comment was moderated, unfortunately.)
+"""]]

Comment moderation
diff --git a/blog/2017-03-02-password-hashers/comment_1_d234fef658c1595bec6fce359a8cec90._comment b/blog/2017-03-02-password-hashers/comment_1_d234fef658c1595bec6fce359a8cec90._comment
new file mode 100644
index 0000000..c6bc23d
--- /dev/null
+++ b/blog/2017-03-02-password-hashers/comment_1_d234fef658c1595bec6fce359a8cec90._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ ip="75.98.19.133"
+ claimedauthor="mvc"
+ subject="What about password maker?"
+ date="2017-03-05T18:58:18Z"
+ content="""
+Interesting discussion...
+
+Have you looked at this algorithm? https://passwordmaker.org/
+I have no reason to think it's an exception to the general shortcomings you noted, but I've never looked into the hash it uses, and after reading your article I'm starting to think I should.
+"""]]

Added a comment: PasswordMaker
diff --git a/blog/2017-03-02-hashers-history/comment_3_03daf97ce071eb323bf5ed4abb1a1db2._comment b/blog/2017-03-02-hashers-history/comment_3_03daf97ce071eb323bf5ed4abb1a1db2._comment
new file mode 100644
index 0000000..fa0ddf1
--- /dev/null
+++ b/blog/2017-03-02-hashers-history/comment_3_03daf97ce071eb323bf5ed4abb1a1db2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="PasswordMaker"
+ date="2017-03-07T14:51:48Z"
+ content="""
+@matt - I had not seen Password Maker when doing my review. I am not sure I would trust that device - I have tried to review the [algorithm detailed here](https://passwordmaker.org/FAQ#How_do_the_account-settings_and_algorithm_I_choose_work_together_to_generate_passwords.3F) and I can't bring myself to trust something that uses a weird `leet()` algorithm - what's that for? I would also question the use of MD5 by default and the practice of allowing so many different hashing solutions. Just choose one, stick to it until it fails then have a graceful way of switching, which is the key problem with password hashers...
+
+This is the difference between \"extensibility\" and \"agility\", the former being better than the latter, as detailed in [this excellent article](https://www.imperialviolet.org/2016/05/16/agility.html). Basically: the more you allow algorithm agility in your protocol, the more open you are to bad algorithms sticking around. Password Maker even supports MD4 there... 
+
+It is interesting to note that Password  Maker has been around since at least as long as my first example here, so it could very well be the first password hasher out there...
+
+@riku - sure, usability is the larger problem here. I have touched that issue the two previous articles in the password series, and I've carefully selected my suggestions based on my (arguably subjective) usability criterion. But it is true a usability article could be interesting. At this point, however, my editors told me that people may become tired of a *fifth* password article (they didn't even accept this fourth one, mind you). ;)
+"""]]

Added a comment: PasswordMaker?
diff --git a/blog/2017-03-02-hashers-history/comment_2_b3db45768c8fe808df757f88d50fa0c8._comment b/blog/2017-03-02-hashers-history/comment_2_b3db45768c8fe808df757f88d50fa0c8._comment
new file mode 100644
index 0000000..c635c6a
--- /dev/null
+++ b/blog/2017-03-02-hashers-history/comment_2_b3db45768c8fe808df757f88d50fa0c8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="69.70.211.62"
+ claimedauthor="Matt C"
+ subject="PasswordMaker?"
+ date="2017-03-07T14:09:43Z"
+ content="""
+Interesting article. Did you consider this hash scheme? https://passwordmaker.org/
+It at least gives you a variety of hash functions.
+"""]]

tone down the criticism on GH, add conclusion
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index af234eb..a402223 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -184,13 +184,16 @@ an email interview, GitHub spokesperson stated that:
 > looking closely at ways to address their concerns.
 
 Regardless, free software enthusiasts have other concerns than the new
-ToS if they wish to use GitHub. It has become a large corporation now
-that created a centralized service (GitHub.com) out of a decentralized
-tool (Git). Most of the software running GitHub is proprietary,
-including the Javascript served to your web browser. It has a critical
-mass which makes it hard to replace and, in a way, "too big to fail",
-which makes GitHub.com a significant liability for the free software
-world.
+ToS if they wish to use GitHub. First and foremost, most of the
+software running GitHub is proprietary, including the Javascript
+served to your web browser. GitHub also created a centralized service
+(GitHub.com) out of a decentralized tool (Git). It has become the
+largest code hosting service in the world after only a few years and
+may very well have become a single point of failure for free software
+collaboration in a way we have never seen before. Outages and policy
+changes at GitHub can have a *major* impact on not only the free
+software world, but also the larger computing world which relies on
+its services for daily operation.
 
 There are now free-software alternatives to GitHub. [GitLab.com][],
 for example, do not seem to have similar licensing issues in its
@@ -206,3 +209,12 @@ score a... F.
 [Open Core]: https://en.wikipedia.org/wiki/Open_core
 [ToS]: https://about.gitlab.com/terms/#gitlab_com
 [GitLab.com]: https://gitlab.com/
+
+In the end, all this controversy could have been avoided if GitHub was
+generally more opened about its development process and would have
+given more time for feedback and reviews by the community. Terms of
+service are notorious for being legally very shady and confusing,
+especially for end users who generally click through without
+reading. We should probably applaud the efforts made by GitHub to make
+its own ToS document actually more readable and hope that, with time,
+they will address the community's concerns.

expand on the CLA issues
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index 305a80d..af234eb 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -111,17 +111,32 @@ actually agreeing with the new ToS.
 
 When I read the first draft of the ToS, I initially thought there
 would be concerns about the mandatory Contributor's License Agreement
-(CLA, [section D.6][]). I managed to find a post from an actual
-lawyer, [Kyle E. Mitchell][mitchell], who [commented][] on the draft
-and, specifically, on the CLA. He outlines issues with wording and
-definition problems in that section of the draft, many of which still
-remains in the final version. Yet considering the stated provisions
-respect the widely accepted norm of "inbound=outbound", it seems that
-section D.6 is not much more problematic than the rest of the ToS.
+(CLA, [section D.5 of the draft][]):
+
+> unless there is a Contributor License Agreement to the contrary,
+> whenever you make a contribution to a repository containing notice
+> of a license, you license your contribution under the same terms,
+> and agree that you have the right to license your contribution under
+> those terms
+
+I was concerned this would force the controversial practice of
+enforcing CLAs on every GitHub users. I managed to find a post from an
+actual lawyer, [Kyle E. Mitchell][mitchell], who [commented][] on the
+draft and, specifically, on the CLA. He outlines issues with wording
+and definition problems in that section of the draft. In particular,
+he noted that "*Contributor license agreement is not a legal term of
+art, but an industry term*" and "*is a bit fuzzy*". This was clarified
+in the final draft, in [section D.6][] by removing the use of the CLA
+term and by explicitly mentioning the widely accepted norm of
+"inbound=outbound". So it seems that section D.6 is not really a
+problem: contributors do not need to *necessarily* delegate copyright
+ownership when they make a contribution, unless otherwise noted by a
+repository-specific CLA.
 
+[section D.6]: https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license
+[section D.5 of the draft]: https://help.github.com/articles/github-terms-of-service-draft/#5-license-grant-to-other-users
 [commented]: https://writing.kemitchell.com/2017/02/16/Against-Legislating-the-Nonobvious.html
 [mitchell]: https://writing.kemitchell.com/
-[section D.6]: https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license
 
 An interesting concern he raised, however, was with *how* GitHub
 conducted the drafting process. A blog post announced the change on

GitHub, they
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index 84a8faa..305a80d 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -1,7 +1,7 @@
-Github terms of service update
+GitHub terms of service update
 ==============================
 
-On February 28th, Github [published][] a brand new version of
+On February 28th, GitHub [published][] a brand new version of
 their [Terms of Service][] (ToS). While the [first draft][] announced
 earlier in February didn't generate much pushback, the new change
 raised concerns that the ToS may break if not the letter, at least
@@ -34,7 +34,7 @@ The concern here is that the ToS *bypass* the normal provisions of
 licenses like the GPL. Indeed, copyleft licenses are based on
 copyright law which forbid users from doing anything with the content
 unless they comply with the license, which forces, among other things,
-"share alike" properties. By granting Github and its users rights to
+"share alike" properties. By granting GitHub and its users rights to
 reproduce content *without* explicitly respecting the original
 license, the ToS may allow users to bypass the copyleft nature of the
 license. Indeed, as Joey Hess, author of Git-annex,
@@ -44,7 +44,7 @@ license. Indeed, as Joey Hess, author of Git-annex,
 > potentially neuters it entirely, so GPL licensed software hosted on
 > Github has an implicit BSD-like license
 
-Hess has since removed all his content (mostly mirrors) from Github.
+Hess has since removed all his content (mostly mirrors) from GitHub.
 
 Others disagree. In a well-reasoned blog post, Debian developer
 Jonathan McDowell [explained][] the rationale behind the changes:
@@ -129,14 +129,14 @@ February 7th with a link to a form to provide feedback until the 21st,
 with a publishing deadline of February 28th. This gave little time for
 lawyers and developers to review the document and provide
 feedback. Users then had to basically accept whatever came out of the
-process as-is. As opposed to every software project hosted on Github,
+process as-is. As opposed to every software project hosted on GitHub,
 the ToS document is not part of a Git repository people can propose
 changes to or even collaboratively discuss. While Mitchell
 acknowledges that "*GitHub are within their rights to update their
 terms, within very broad limits, more or less however they like,
 whenever they like*", he sets higher standards for GitHub than for
-other corporations, considering the community they serve and the
-spirit they represent. He described the process as:
+other corporations, considering the community it serves and the
+spirit it represents. He described the process as:
 
 > [...] consistent with the value of CYA, which is real, but not with
 > the output-improving virtues of open process, which is also real,
@@ -157,12 +157,12 @@ major impact on the free software world. As Mitchell outlines:
 > can do real damage.
 
 However, it seems that GitHub has actually been proactive in reaching
-out to the free software community. Kuhn explained that they actually
+out to the free software community. Kuhn explained that it actually
 contacted the Conservancy to get their advice on the ToS changes.
 While he still thinks GitHub should fix the ambiguities quickly, he
 also noted that those issues "*impact pretty much any non-trivial Open
-Source and Free Software license*", not just copylefted material. When
-reached for comments, a GitHub spokesperson replied that:
+Source and Free Software license*", not just copylefted material. In
+an email interview, GitHub spokesperson stated that:
 
 > While we are confident that these Terms serve the best needs of the
 > community, we take our users’ feedback very seriously and we are
@@ -178,7 +178,7 @@ which makes GitHub.com a significant liability for the free software
 world.
 
 There are now free-software alternatives to GitHub. [GitLab.com][],
-for example, do not seem to have similar licensing issues in their
+for example, do not seem to have similar licensing issues in its
 [ToS][] and GitLab itself is free software, although based on the
 controversial [Open Core][] business model. The GitLab hosting service
 still has to go beyond grade C in the

integrate github quote
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index 3591df3..84a8faa 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -161,9 +161,14 @@ out to the free software community. Kuhn explained that they actually
 contacted the Conservancy to get their advice on the ToS changes.
 While he still thinks GitHub should fix the ambiguities quickly, he
 also noted that those issues "*impact pretty much any non-trivial Open
-Source and Free Software license*", not just copylefted material.
+Source and Free Software license*", not just copylefted material. When
+reached for comments, a GitHub spokesperson replied that:
 
-Besides, free software enthusiasts have other concerns than the new
+> While we are confident that these Terms serve the best needs of the
+> community, we take our users’ feedback very seriously and we are
+> looking closely at ways to address their concerns.
+
+Regardless, free software enthusiasts have other concerns than the new
 ToS if they wish to use GitHub. It has become a large corporation now
 that created a centralized service (GitHub.com) out of a decentralized
 tool (Git). Most of the software running GitHub is proprietary,
@@ -181,8 +186,6 @@ still has to go beyond grade C in the
 [worked on][]) whereas other services like GitHub and SourceForge
 score a... F.
 
-GitHub couldn't be reached for comment at the time of writing.
-
 [worked on]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15677
 [GNU Ethical Repository Criteria Evaluations]: https://www.gnu.org/software/repo-criteria-evaluation.html
 [Open Core]: https://en.wikipedia.org/wiki/Open_core

final review
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
index eb6988f..3591df3 100644
--- a/blog/github-tos.mdwn
+++ b/blog/github-tos.mdwn
@@ -4,21 +4,19 @@ Github terms of service update
 On February 28th, Github [published][] a brand new version of
 their [Terms of Service][] (ToS). While the [first draft][] announced
 earlier in February didn't generate much pushback, the new change
-created concerns that the ToS may break if not the letter, at least
+raised concerns that the ToS may break if not the letter, at least
 the spirit of certain free software licenses.
 
 [first draft]: https://github.com/blog/2314-new-github-terms-of-service
 [Terms of Service]: https://help.github.com/articles/github-terms-of-service/
 [published]: https://github.com/blog/2327-new-github-terms-of-service-are-in-effect
 
-Where are those concerns coming from? The first person to raise the
-alarm was probably Thorsten Glaser, a Debian developer,
-who [announced][] that the "*new GitHub Terms of Service r̲e̲q̲u̲i̲r̲e̲
-removing many Open Source works from it*". His concerns are mainly
-around [section D][] of the document. One of the problematic parts is
+The first person to raise the alarm was probably Thorsten Glaser, a
+Debian developer, who [announced][] that the "*new GitHub Terms of
+Service require removing many Open Source works from it*". His
+concerns are mainly around [section D][] of the document, for example
 section D.4 which states that:
 
-[section D]: https://help.github.com/articles/github-terms-of-service/#d-user-generated-content
 [announced]: https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm
 
 > You grant us and our legal successors the right to store and display
@@ -39,7 +37,7 @@ unless they comply with the license, which forces, among other things,
 "share alike" properties. By granting Github and its users rights to
 reproduce content *without* explicitly respecting the original
 license, the ToS may allow users to bypass the copyleft nature of the
-license. Indeed, as Joey Hess
+license. Indeed, as Joey Hess, author of Git-annex,
 [explained](http://joeyh.name/blog/entry/removing_everything_from_github/) :
 
 > The new TOS is potentially very bad for copylefted Free Software. It
@@ -48,8 +46,8 @@ license. Indeed, as Joey Hess
 
 Hess has since removed all his content (mostly mirrors) from Github.
 
-Others disagree. In a well-reasoned blog post, Jonathan McDowell, a
-fellow Debian developer, [explained][] the rationale behind the changes:
+Others disagree. In a well-reasoned blog post, Debian developer
+Jonathan McDowell [explained][] the rationale behind the changes:
 
 [explained]: https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html
 
@@ -98,7 +96,7 @@ explained:
 He went even further and stated that "*we should assume the ambiguity
 in their ToS as it stands is favorable to Free Software*".
 
-The ToS are [effective][] since February 28th and users "*can accept
+The ToS are in effect since February 28th and users "*can accept
 them by clicking the broadcast announcement on your dashboard or by
 continuing to use GitHub*". The immediacy of the change is one of the
 reasons why certain people are rushing to remove content from GitHub:
@@ -110,39 +108,39 @@ user should remove their content from the GitHub servers without
 actually agreeing with the new ToS.
 
 [separete copy of the ToS]: https://tmp.joeyh.name/github-tos.pdf
-[effective]: https://github.com/blog/2327-new-github-terms-of-service-are-in-effect
 
 When I read the first draft of the ToS, I initially thought there
 would be concerns about the mandatory Contributor's License Agreement
-(CLA, [section D.6][]). I managed to find a post from
-an [actual lawyer][] who [commented][] on the draft and, specifically,
-on the CLA. He outlines issues with wording and definition problems in
-that section of the draft, many of which still remains in the final
-version. Yet considering the stated provisions respect the widely
-accepted norm of "inbound=outbound", it seems that section D.6 is not
-much more problematic than the rest of the ToS.
+(CLA, [section D.6][]). I managed to find a post from an actual
+lawyer, [Kyle E. Mitchell][mitchell], who [commented][] on the draft
+and, specifically, on the CLA. He outlines issues with wording and
+definition problems in that section of the draft, many of which still
+remains in the final version. Yet considering the stated provisions
+respect the widely accepted norm of "inbound=outbound", it seems that
+section D.6 is not much more problematic than the rest of the ToS.
 
 [commented]: https://writing.kemitchell.com/2017/02/16/Against-Legislating-the-Nonobvious.html
-[actual lawyer]: https://writing.kemitchell.com/
+[mitchell]: https://writing.kemitchell.com/
 [section D.6]: https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license
 
-An interesting concern he raised, however, was with *how* GitHub the
-drafting consulting process. A blog post announced the change on
+An interesting concern he raised, however, was with *how* GitHub
+conducted the drafting process. A blog post announced the change on
 February 7th with a link to a form to provide feedback until the 21st,
 with a publishing deadline of February 28th. This gave little time for
-lawyers and developers to review the document, provide feedback and
-basically accept whatever came out of it. As opposed to every software
-project hosted on Github, the ToS document is not part of a Git
-repository people can propose changes to or even collaboratively
-discuss. While Mitchell acknowledges that "*GitHub are within their
-rights to update their terms, within very broad limits, more or less
-however they like, whenever they like*", he sets higher standards for
-GitHub than for other corporations, considering the community they
-serve and the spirit they represent:
-
-> In other words, it’s consistent with the value of CYA, which is
-> real, but not with the output-improving virtues of open process,
-> which is also real, and a great deal more pleasant.
+lawyers and developers to review the document and provide
+feedback. Users then had to basically accept whatever came out of the
+process as-is. As opposed to every software project hosted on Github,
+the ToS document is not part of a Git repository people can propose
+changes to or even collaboratively discuss. While Mitchell
+acknowledges that "*GitHub are within their rights to update their
+terms, within very broad limits, more or less however they like,
+whenever they like*", he sets higher standards for GitHub than for
+other corporations, considering the community they serve and the
+spirit they represent. He described the process as:
+
+> [...] consistent with the value of CYA, which is real, but not with
+> the output-improving virtues of open process, which is also real,
+> and a great deal more pleasant.
 
 Furthermore, there may be concerns that the ToS change may be an
 attempt to further the already[diminishing adoption][] of the GPL for
@@ -168,19 +166,22 @@ Source and Free Software license*", not just copylefted material.
 Besides, free software enthusiasts have other concerns than the new
 ToS if they wish to use GitHub. It has become a large corporation now
 that created a centralized service (GitHub.com) out of a decentralized
-tool (Git). Most of the software GitHub uses is proprietary, including
-the Javascript served to your web browser. It has a critical mass
-which makes it hard to replace and, in a way, "too big to fail", which
-is therefore a significant liability for the free software world.
+tool (Git). Most of the software running GitHub is proprietary,
+including the Javascript served to your web browser. It has a critical
+mass which makes it hard to replace and, in a way, "too big to fail",
+which makes GitHub.com a significant liability for the free software
+world.
 
 There are now free-software alternatives to GitHub. [GitLab.com][],
-for example, do not seem to have similar licensing issues in
-their [ToS][] and GitLab itself is free software, although based on
-the controversial [Open Core][] business model. The GitLab service
-hosting still has to go beyond grade C in
-the [GNU Ethical Repository Criteria Evaluations][] (and this is
-being [worked on][]) whereas other services like GitHub and
-SourceForge score a... F.
+for example, do not seem to have similar licensing issues in their
+[ToS][] and GitLab itself is free software, although based on the
+controversial [Open Core][] business model. The GitLab hosting service
+still has to go beyond grade C in the
+[GNU Ethical Repository Criteria Evaluations][] (and this is being
+[worked on][]) whereas other services like GitHub and SourceForge
+score a... F.
+
+GitHub couldn't be reached for comment at the time of writing.
 
 [worked on]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15677
 [GNU Ethical Repository Criteria Evaluations]: https://www.gnu.org/software/repo-criteria-evaluation.html

Added a comment: Great article
diff --git a/blog/2017-03-02-hashers-history/comment_1_f03e489c70e9e0f2b1224fb24cb7c69a._comment b/blog/2017-03-02-hashers-history/comment_1_f03e489c70e9e0f2b1224fb24cb7c69a._comment
new file mode 100644
index 0000000..8ce526d
--- /dev/null
+++ b/blog/2017-03-02-hashers-history/comment_1_f03e489c70e9e0f2b1224fb24cb7c69a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ ip="91.157.170.157"
+ claimedauthor="Riku Voipio"
+ subject="Great article"
+ date="2017-03-03T08:15:42Z"
+ content="""
+Hi,
+
+This was an exceptional article - like previous ones in your series. There is, however, a danger of loosing the big picture when delving into algorithmic details. And I think the big picture is in usability. If the password manager or hasher is too inconvenient, people won't just use them - and are worse off than when using MD5-hashed site-specific passwords.
+
+It would be interesting finish of the article series with usability comparison between the most cryptographically sound  password managers and hashers.
+
+
+"""]]

first draft for gh tos change
diff --git a/blog/github-tos.mdwn b/blog/github-tos.mdwn
new file mode 100644
index 0000000..eb6988f
--- /dev/null
+++ b/blog/github-tos.mdwn
@@ -0,0 +1,189 @@
+Github terms of service update
+==============================
+
+On February 28th, Github [published][] a brand new version of
+their [Terms of Service][] (ToS). While the [first draft][] announced
+earlier in February didn't generate much pushback, the new change
+created concerns that the ToS may break if not the letter, at least
+the spirit of certain free software licenses.
+
+[first draft]: https://github.com/blog/2314-new-github-terms-of-service
+[Terms of Service]: https://help.github.com/articles/github-terms-of-service/
+[published]: https://github.com/blog/2327-new-github-terms-of-service-are-in-effect
+
+Where are those concerns coming from? The first person to raise the
+alarm was probably Thorsten Glaser, a Debian developer,
+who [announced][] that the "*new GitHub Terms of Service r̲e̲q̲u̲i̲r̲e̲
+removing many Open Source works from it*". His concerns are mainly
+around [section D][] of the document. One of the problematic parts is
+section D.4 which states that:
+
+[section D]: https://help.github.com/articles/github-terms-of-service/#d-user-generated-content
+[announced]: https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm
+
+> You grant us and our legal successors the right to store and display
+> your Content and make incidental copies as necessary to render the
+> Website and provide the Service.
+
+Section D.5 then goes on to state that:
+
+> [...] You grant each User of GitHub a nonexclusive, worldwide
+> license to access your Content through the GitHub Service, and to
+> use, display and perform your Content, and to reproduce your Content
+> solely on GitHub as permitted through GitHub's functionality
+
+The concern here is that the ToS *bypass* the normal provisions of
+licenses like the GPL. Indeed, copyleft licenses are based on
+copyright law which forbid users from doing anything with the content
+unless they comply with the license, which forces, among other things,
+"share alike" properties. By granting Github and its users rights to
+reproduce content *without* explicitly respecting the original
+license, the ToS may allow users to bypass the copyleft nature of the
+license. Indeed, as Joey Hess
+[explained](http://joeyh.name/blog/entry/removing_everything_from_github/) :
+
+> The new TOS is potentially very bad for copylefted Free Software. It
+> potentially neuters it entirely, so GPL licensed software hosted on
+> Github has an implicit BSD-like license
+
+Hess has since removed all his content (mostly mirrors) from Github.
+
+Others disagree. In a well-reasoned blog post, Jonathan McDowell, a
+fellow Debian developer, [explained][] the rationale behind the changes:
+
+[explained]: https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html
+
+> My reading of the GitHub changes is that they are driven by a desire
+> to ensure that GitHub are legally covered for the things they need
+> to do with your code in order to run their service.
+
+This seems like a fair point to make: GitHub needs to protect its own
+rights to operate the service. McDowell then goes on to do a detailed
+rebuttal of the arguments brought by Glaser, arguing specifically that
+section D.5 "*does not grant [...] additional rights to reproduce
+outside of GitHub*".
+
+However, specific problems arise when we consider that GitHub is a
+private corporation that users have no control over. The "*Services*"
+defined in the ToS explicitly "*refers to the applications, software,
+products, and services provided by GitHub*". The term "Services" is
+therefore not limited to the current set of services. This loophole
+may actually give GitHub the right to bypass certain provisions of
+licenses used on GitHub. As Hess detailed in a
+[later blog post](http://joeyh.name/blog/entry/what_I_would_ask_my_lawyers_about_the_new_Github_TOS/):
+
+> If Github tomorrow starts providing say, an App Store service, that
+> necessarily involves distribution of software to others, and they
+> put my software in it, would that be allowed by this or not?
+
+> If that hypothetical Github App Store doesn't sell apps, but
+> licenses access to them for money, would that be allowed under this
+> license that they want to my software?
+
+In an interview, however, Bradley M. Kuhn, of Software Freedom
+Conservancy, explained that "*ultimately, failure to comply with a
+copyleft license is a copyright infringement*" and that the ToS do
+outline a process to deal with such infringement. Some lawyers have
+also publicly expressed their disagreement with Glaser's assessment,
+with
+[Richard Fontana](https://twitter.com/richardfontana/status/837370085392199681) from
+Red Hat saying that the analysis is "*basically wrong*". It all comes
+down to the intent of the ToS, as Kuhn (who is not a lawyer)
+explained:
+
+> *any* license can be abused or misused for an intent other than its
+> original intent. It's why it matters to get every little detail
+> right, and I hope Github will do that.
+
+He went even further and stated that "*we should assume the ambiguity
+in their ToS as it stands is favorable to Free Software*".
+
+The ToS are [effective][] since February 28th and users "*can accept
+them by clicking the broadcast announcement on your dashboard or by
+continuing to use GitHub*". The immediacy of the change is one of the
+reasons why certain people are rushing to remove content from GitHub:
+there are concerns that their continuous use of the service may be
+interpreted as consent to bypass those licenses. Hess even hosted
+a [separete copy of the ToS][] for people to be able to read the
+document without implicitly consenting. It is, however, unclear how a
+user should remove their content from the GitHub servers without
+actually agreeing with the new ToS.
+
+[separete copy of the ToS]: https://tmp.joeyh.name/github-tos.pdf
+[effective]: https://github.com/blog/2327-new-github-terms-of-service-are-in-effect
+
+When I read the first draft of the ToS, I initially thought there
+would be concerns about the mandatory Contributor's License Agreement
+(CLA, [section D.6][]). I managed to find a post from
+an [actual lawyer][] who [commented][] on the draft and, specifically,
+on the CLA. He outlines issues with wording and definition problems in
+that section of the draft, many of which still remains in the final
+version. Yet considering the stated provisions respect the widely
+accepted norm of "inbound=outbound", it seems that section D.6 is not
+much more problematic than the rest of the ToS.
+
+[commented]: https://writing.kemitchell.com/2017/02/16/Against-Legislating-the-Nonobvious.html
+[actual lawyer]: https://writing.kemitchell.com/
+[section D.6]: https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license
+
+An interesting concern he raised, however, was with *how* GitHub the
+drafting consulting process. A blog post announced the change on
+February 7th with a link to a form to provide feedback until the 21st,
+with a publishing deadline of February 28th. This gave little time for
+lawyers and developers to review the document, provide feedback and
+basically accept whatever came out of it. As opposed to every software
+project hosted on Github, the ToS document is not part of a Git
+repository people can propose changes to or even collaboratively
+discuss. While Mitchell acknowledges that "*GitHub are within their
+rights to update their terms, within very broad limits, more or less
+however they like, whenever they like*", he sets higher standards for
+GitHub than for other corporations, considering the community they
+serve and the spirit they represent:
+
+> In other words, it’s consistent with the value of CYA, which is
+> real, but not with the output-improving virtues of open process,
+> which is also real, and a great deal more pleasant.
+
+Furthermore, there may be concerns that the ToS change may be an
+attempt to further the already[diminishing adoption][] of the GPL for
+free software project, which is now [surpassed][] by the MIT license
+on GitHub. GitHub formalizing this change in its ToS could have a
+major impact on the free software world. As Mitchell outlines:
+
+[surpassed]: https://github.com/blog/1964-license-usage-on-github-com
+[diminishing adoption]: https://en.wikipedia.org/wiki/GNU_General_Public_License#Adoption
+
+> And as the current forum of preference for a great many developers,
+> the knock-on effects of their decisions throw big weight. While
+> GitHub have the wheel—and they’ve certainly earned it for now—they
+> can do real damage.
+
+However, it seems that GitHub has actually been proactive in reaching
+out to the free software community. Kuhn explained that they actually
+contacted the Conservancy to get their advice on the ToS changes.
+While he still thinks GitHub should fix the ambiguities quickly, he
+also noted that those issues "*impact pretty much any non-trivial Open
+Source and Free Software license*", not just copylefted material.
+
+Besides, free software enthusiasts have other concerns than the new
+ToS if they wish to use GitHub. It has become a large corporation now
+that created a centralized service (GitHub.com) out of a decentralized
+tool (Git). Most of the software GitHub uses is proprietary, including
+the Javascript served to your web browser. It has a critical mass
+which makes it hard to replace and, in a way, "too big to fail", which
+is therefore a significant liability for the free software world.
+
+There are now free-software alternatives to GitHub. [GitLab.com][],
+for example, do not seem to have similar licensing issues in
+their [ToS][] and GitLab itself is free software, although based on
+the controversial [Open Core][] business model. The GitLab service
+hosting still has to go beyond grade C in
+the [GNU Ethical Repository Criteria Evaluations][] (and this is
+being [worked on][]) whereas other services like GitHub and
+SourceForge score a... F.
+
+[worked on]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15677
+[GNU Ethical Repository Criteria Evaluations]: https://www.gnu.org/software/repo-criteria-evaluation.html
+[Open Core]: https://en.wikipedia.org/wiki/Open_core
+[ToS]: https://about.gitlab.com/terms/#gitlab_com
+[GitLab.com]: https://gitlab.com/

finish redaction of history
diff --git a/blog/2017-03-02-hashers-history.mdwn b/blog/2017-03-02-hashers-history.mdwn
index 2ed6264..4637d3d 100644
--- a/blog/2017-03-02-hashers-history.mdwn
+++ b/blog/2017-03-02-hashers-history.mdwn
@@ -1,95 +1,116 @@
-A short history of password hashers
------------------------------------
-
-Since the concept is so old, it may be useful to go over a
-short history of notable password hashers, before we go
-into issues specific to their implementation.
-
-[Nic Wolff](http://angel.net/~nic/passwd.current.html)
-[claims](https://news.ycombinator.com/item?id=12892655) to be the
-first to have written such a program, all the
-[way back in 2003](http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html). Back
-then the hashing algorithm was [MD5](https://en.wikipedia.org/wiki/MD5), although Wolff has now updated the
-algorithm to use [SHA-1](https://en.wikipedia.org/wiki/SHA-1) and still maintains his webpage for public
-use. Another ancient but unrelated implementation, is the Standford
-University Applied Cryptography's
-[pwdhash](https://crypto.stanford.edu/PwdHash) software. That
-implementation was
-[published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/)
-and unfortunately, that implementation was not updated and still uses
-MD5 as an hashing algorithm, but at least it uses
-[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)
-to generate tokens, which makes the use of
-[rainbow tables](https://en.wikipedia.org/wiki/Rainbow_table)
-impractical. Those implementations are the simplest
-password hashers: the inputs are simply the site URL and a
+[[!meta title="A short history of password hashers"]]
+[[!meta updated="2017-03-02T09:45:36-0500"]]
+
+These are notes from my research that led to the publication of the
+[[password hashers|2017-03-02-password-hashers]] article. This article
+is more technical than the previous ones and compares the various
+cryptographic primitives and algorithms used in the various software I
+have reviewed. The criteria for inclusion on this list is fairly
+vague: I mostly included a password hasher if it was significantly
+different from the previous implementations in some way, and I have
+included all the major ones I could find as well.
+
+[[!toc levels=2]]
+
+The first password hashers
+---------------------------
+
+[Nic Wolff][] [claims][] to be the first to have written such a
+program, all the [way back in 2003][]. Back then the hashing algorithm
+was [MD5][], although Wolff has now updated the algorithm to
+use [SHA-1][] and still maintains his webpage for public use. Another
+ancient but unrelated implementation, is the Standford University
+Applied Cryptography's [pwdhash][] software. That implementation
+was [published in 2004][] and unfortunately, that implementation was
+not updated and still uses MD5 as an hashing algorithm, but at least
+it uses [HMAC][] to generate tokens, which makes the use
+of [rainbow tables][] impractical. Those implementations are the
+simplest password hashers: the inputs are simply the site URL and a
 password. So the algorithms are, basically, for Wolff's:
 
     token = base64(SHA1(password + domain))
 
-And for [Standford's PwdHash](https://www.pwdhash.com/hashed-password.js):
+[rainbow tables]: https://en.wikipedia.org/wiki/Rainbow_table
+[HMAC]: https://en.wikipedia.org/wiki/Hash-based_message_authentication_code
+[published in 2004]: https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/
+[pwdhash]: https://crypto.stanford.edu/PwdHash
+[SHA-1]: https://en.wikipedia.org/wiki/SHA-1
+[MD5]: https://en.wikipedia.org/wiki/MD5
+[way back in 2003]: http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html
+[claims]: https://news.ycombinator.com/item?id=12892655
+[Nic Wolff]: http://angel.net/~nic/passwd.current.html
+
+And for [Standford's PwdHash][]:
 
     token = base64(HMAC(MD5, password, domain)))
 
-Another unrelated implementation that is still around is
-[supergenpass](https://chriszarate.github.io/supergenpass/) is a
-bookmarklet that was
-[created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
+[Standford's PwdHash]: https://www.pwdhash.com/hashed-password.js
+
+SuperGenPass
+------------
+
+Another unrelated implementation that is still around
+is [supergenpass][] is a bookmarklet that was [created around 2007][],
 originally using MD5 as well but now supports SHA512 now although
-still
-[limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
-(which needlessly limits the entropy of the resulting password)
-and still
-[defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
-with
-[not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
-(10, when key derivation recommendations are more generally around 10
-000, so that it's slower to bruteforce).
-
-Note that Chris Zarate, the supergenpass author, actually
-credits Nic Wolff as the inspiration for his
-implementation. Supergenpass is still in active development and is
-available for the browser (as a
-[bookmarklet](https://chriszarate.github.io/supergenpass/)) or mobile
-(as an
-[webpage](https://chriszarate.github.io/supergenpass/mobile/)). Supergenpass
-allows you to modify the password length, but also add an extra
-profile secret which adds to the password and generates a personalized
-[identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
-prevent phishing but it also introduces the interesting protection,
-the profile-specific secret only found later in Password Hasher Plus. So the
-[Supergenpass algorithm](https://github.com/chriszarate/supergenpass-lib/blob/eb9ee92050813d498229bfe0e6ccbcb87124cf90/src/lib/generate.js#L32) looks something like this:
+still [limited to 24 characters like MD5][] (which needlessly limits
+the entropy of the resulting password) and still [defaults MD5][]
+with [not enough rounds][] (10, when key derivation recommendations
+are more generally around 10 000, so that it's slower to bruteforce).
+
+[not enough rounds]: https://github.com/chriszarate/supergenpass/issues/82
+[defaults MD5]: https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66
+[limited to 24 characters like MD5]: https://github.com/chriszarate/supergenpass/issues/85
+[created around 2007]: http://web.archive.org/web/20071116095006/http://supergenpass.com/
+[supergenpass]: https://chriszarate.github.io/supergenpass/
+
+Note that Chris Zarate, the supergenpass author, actually credits Nic
+Wolff as the inspiration for his implementation. Supergenpass is still
+in active development and is available for the browser (as
+a [bookmarklet][]) or mobile (as an [webpage][]). Supergenpass allows
+you to modify the password length, but also add an extra profile
+secret which adds to the password and generates a
+personalized [identicon][] presumably to prevent phishing but it also
+introduces the interesting protection, the profile-specific secret
+only found later in Password Hasher Plus. So
+the [Supergenpass algorithm][] looks something like this:
 
     token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
 
-Another popular implementation is the Wijjo Password Hasher,
-[created around 2006](http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/).
-It was probably the first shipped as a
-[browser extension](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
-which greatly improved the security of the product as users didn't
-have to continually download the software on the fly. Wijjo's
-algorithm also improved on the above algorithms, as it uses HMAC-SHA1
-instead of plain SHA-1 or HMAC-MD5, which makes it harder to recover
-the plaintext. Password Hasher allows you to set different password
-policies (use digits, punctuation, mixed case, special characters and
-password length) and saves the site names it uses for future
-reference. It also happens that the Wijjo Password Hasher, in turn,
-took its inspiration on *different* project,
-[hashapass.com](http://www.hashapass.com/),
-[created in 2006](http://web.archive.org/web/20060702050519/http://www.hashapass.com/)
-and also based on
-HMAC-SHA-1. [Indeed](http://www.hashapass.com/en/cmd.html), hashapass
-"can easily be generated on almost any modern Unix-like system using
-the following command line pattern":
+[Supergenpass algorithm]: https://github.com/chriszarate/supergenpass-lib/blob/eb9ee92050813d498229bfe0e6ccbcb87124cf90/src/lib/generate.js#L32
+[identicon]: https://en.wikipedia.org/wiki/Identicon
+[webpage]: https://chriszarate.github.io/supergenpass/mobile/
+[bookmarklet]: https://chriszarate.github.io/supergenpass/
+
+The Wijjo Password Hasher
+-------------------------
+
+Another popular implementation is the Wijjo Password
+Hasher, [created around 2006][].  It was probably the first shipped as
+a [browser extension][] which greatly improved the security of the
+product as users didn't have to continually download the software on
+the fly. Wijjo's algorithm also improved on the above algorithms, as
+it uses HMAC-SHA1 instead of plain SHA-1 or HMAC-MD5, which makes it
+harder to recover the plaintext. Password Hasher allows you to set
+different password policies (use digits, punctuation, mixed case,
+special characters and password length) and saves the site names it
+uses for future reference. It also happens that the Wijjo Password
+Hasher, in turn, took its inspiration on *different*
+project, [hashapass.com][], [created in 2006][] and also based on
+HMAC-SHA-1. [Indeed][], hashapass "can easily be generated on almost
+any modern Unix-like system using the following command line pattern":
 
     echo -n parameter \
     | openssl dgst -sha1 -binary -hmac password \
     | openssl enc -base64 \
     | cut -c 1-8
 
-So the
-[algorithm](https://addons.mozilla.org/en-US/firefox/files/browse/140427/file/chrome/content/passhash-common.js#L298)
-here is obviously:
+[Indeed]: http://www.hashapass.com/en/cmd.html
+[created in 2006]: http://web.archive.org/web/20060702050519/http://www.hashapass.com/
+[hashapass.com]: http://www.hashapass.com/
+[browser extension]: https://addons.mozilla.org/en-US/firefox/addon/password-hasher/
+[created around 2006]: http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/
+
+So the [algorithm][] here is obviously:
 
     token = base64(HMAC(SHA1, password, domain + ":" + counter)))[:8]
 
@@ -97,9 +118,12 @@ here is obviously:
 routine that takes the token and inserts random characters in locations
 determined by the sum of the values of the characters in the token.
 

(Diff truncated)
convert hashers article
diff --git a/blog/2017-03-02-password-hashers.mdwn b/blog/2017-03-02-password-hashers.mdwn
index 472bf20..41668fd 100644
--- a/blog/2017-03-02-password-hashers.mdwn
+++ b/blog/2017-03-02-password-hashers.mdwn
@@ -1,12 +1,14 @@
-The case against password hashers
-=================================
+[[!meta title="The case against password hashers"]]
+[[!meta date="2017-02-22T12:00:00-0500"]]
+[[!meta updated="2017-03-02T09:02:30-0500"]]
 
-In previous articles, we have looked at [how to generate
-passwords](https://lwn.net/Articles/713806/) and did a [review of
-various password managers](https://lwn.net/Articles/714473/). There is,
-however, a third way of managing passwords other than remembering them
-or encrypting them in a "vault", which is what I call "password
-hashing".
+[[!toc startlevel=2]]
+
+In previous articles, we have looked at [[how to generate
+passwords|2017-02-18-passwords-entropy]] and did a [[review of various
+password managers|2017-02-22-password-managers]]. There is, however, a
+third way of managing passwords other than remembering them or
+encrypting them in a "vault", which is what I call "password hashing".
 
 A password hasher generates site-specific passwords from a single master
 password using a cryptographic hash function. It thus allows a user to
@@ -25,7 +27,7 @@ the user doesn't need to remember. The input to a password hasher is a
 password with some site-specific context and the output from a password
 hasher is a token.
 
-#### What is a password hasher?
+## What is a password hasher?
 
 A password hasher uses the master password and a label (generally the
 host name) to generate the site-specific password. To change the
@@ -34,35 +36,34 @@ appending a number. Some password hashers also have different settings
 to generate tokens of different lengths or compositions (symbols or not,
 etc.) to accommodate different site-specific password policies.
 
-The whole concept of password hashers relies on the concept of one-way
-[cryptographic hash
-functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function) or
-[key derivation
-functions](https://en.wikipedia.org/wiki/Key_derivation_function) that
-take an arbitrary input string (say a password) and generate a unique
-token, from which it is impossible to guess the original input string.
-Password hashers are generally written as JavaScript bookmarklets or
-browser plugins and have been around for over a decade.
+The whole concept of password hashers relies on the concept of
+one-way [cryptographic hash functions][]
+or [key derivation functions][] that take an arbitrary input string
+(say a password) and generate a unique token, from which it is
+impossible to guess the original input string.  Password hashers are
+generally written as JavaScript bookmarklets or browser plugins and
+have been around for over a decade.
+
+[key derivation functions]: https://en.wikipedia.org/wiki/Key_derivation_function
+[cryptographic hash functions]: https://en.wikipedia.org/wiki/Cryptographic_hash_function
 
 The biggest advantage of password hashers is that you only need to
 remember a single password. You do not need to carry around a password
 manager vault: there's no "state" (other than site-specific settings,
-which can be easily guessed). A password hasher named [Master
-Password](https://ssl.masterpasswordapp.com/) makes a compelling case
-against traditional password managers in its
-[documentation](https://ssl.masterpasswordapp.com/security.html#loss):
+which can be easily guessed). A password hasher
+named [Master Password][] makes a compelling case against traditional
+password managers in its [documentation][]:
 
-<div class="BigQuote">
+[documentation]: https://ssl.masterpasswordapp.com/security.html#loss
+[Master Password]: https://ssl.masterpasswordapp.com/
 
-It's as though the implicit assumptions are that everybody backs all of
-their stuff up to at least two different devices and backups in the
-cloud in at least two separate countries. Well, **people don't always
-have perfect backups**. In fact, they usually don't have *any*.
+> It's as though the implicit assumptions are that everybody backs all of
+> their stuff up to at least two different devices and backups in the
+> cloud in at least two separate countries. Well, **people don't always
+> have perfect backups**. In fact, they usually don't have *any*.
 
-</div>
-
-It goes on to argue that, when you lose your password: "<span>You lose
-everything. You lose your own identity.</span>"
+It goes on to argue that, when you lose your password: "*You lose
+everything. You lose your own identity.*"
 
 The stateless nature of password hashers also means you do not need to
 use cloud services to synchronize your passwords, as there is
@@ -80,56 +81,59 @@ every site you use them on. While you can also do this with password
 managers, it is not an enforced decision. With hashers, you get distinct
 and strong passwords for every site with no effort.
 
-#### The problem with password hashers
+## The problem with password hashers
 
 If hashers are so great, why would you use a password manager? Programs
-like [LessPass](https://lesspass.com/) and Master Password seem to have
+like [LessPass][] and Master Password seem to have
 strong crypto that is well implemented, so why isn't everyone using
 those tools?
 
+[LessPass]: https://lesspass.com/
+
 Password hashing, as a general concept, actually has serious problems:
 since the hashing outputs are constantly compromised (they are sent in
 password forms to various possibly hostile sites), it's theoretically
-possible to derive the master password and then break all the generated
-tokens in one shot. The use of stronger key derivation functions (like
-[PBKDF2](https://en.wikipedia.org/wiki/PBKDF2),
-[scrypt](https://en.wikipedia.org/wiki/scrypt), or
-[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code))
-or seeds (like a profile-specific secret) makes those attacks much
-harder, especially if the seed is long enough to make brute-force
-attacks infeasible. (Unfortunately, in the case of [Password Hasher
-Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd),
-the seed is derived from `Math.random()` calls, which are [not
-considered cryptographically
-secure](http://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure).)
-
-Basically, as stated by Julian Morrison in [this
-discussion](https://news.ycombinator.com/item?id=12890997):
-
-<div class="BigQuote">
-
-A password is now ciphertext, not a block of line noise. Every time you
-transmit it, you are giving away potential clues of use to an attacker.
-\[...\]
-You only have one password for all the sites, really, underneath, and
-it's your secret key. If it's broken, it's now a skeleton-key \[...\]
-
-</div>
+possible to derive the master password and then break all the
+generated tokens in one shot. The use of stronger key derivation
+functions (like [PBKDF2][], [scrypt][], or [HMAC][]) or seeds (like a
+profile-specific secret) makes those attacks much harder, especially
+if the seed is long enough to make brute-force attacks
+infeasible. (Unfortunately, in the case of [Password Hasher Plus][],
+the seed is derived from `Math.random()` calls, which
+are [not considered cryptographically secure][].)
+
+[not considered cryptographically secure]: http://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure
+[Password Hasher Plus]: https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd
+[HMAC]: https://en.wikipedia.org/wiki/Hash-based_message_authentication_code
+[scrypt]: https://en.wikipedia.org/wiki/scrypt
+[PBKDF2]: https://en.wikipedia.org/wiki/PBKDF2
+
+Basically, as stated by Julian Morrison in [this discussion][]:
+
+[this discussion]: https://news.ycombinator.com/item?id=12890997
+
+> A password is now ciphertext, not a block of line noise. Every time you
+> transmit it, you are giving away potential clues of use to an attacker.
+> [...]
+> You only have one password for all the sites, really, underneath, and
+> it's your secret key. If it's broken, it's now a skeleton-key [...]
 
 Newer implementations like LessPass and Master Password fix this by
 using reasonable key derivation algorithms (PBKDF2 and scrypt,
 respectively) that are more resistant to offline cracking attacks, but
 who knows how long those will hold? To give a concrete example, if you
 would like to use the new winner of the password hashing competition
-([Argon2](https://en.wikipedia.org/wiki/Argon2)) in your password
-manager, you can patch the program (or wait for an update) and
-re-encrypt your database. With a password hasher, it's not so easy:
-changing the algorithm means logging in to *every* site you visited and
-changing the password. As someone who used a password hasher for a few
-years, I can tell you this is really impractical: you quickly end up
-with *hundreds* of passwords. The LessPass developers tried to
-facilitate this, but they ended up mostly [giving
-up](https://github.com/lesspass/lesspass/issues/36).
+([Argon2][]) in your password manager, you can patch the program (or
+wait for an update) and re-encrypt your database. With a password
+hasher, it's not so easy: changing the algorithm means logging in to
+*every* site you visited and changing the password. As someone who
+used a password hasher for a few years, I can tell you this is really
+impractical: you quickly end up with *hundreds* of passwords. The
+LessPass developers tried to facilitate this, but they ended up
+mostly [giving up][].
+
+[giving up]: https://github.com/lesspass/lesspass/issues/36
+[Argon2]: https://en.wikipedia.org/wiki/Argon2
 
 Which brings us to the question of state. A lot of those tools claim to
 work "without a server" or as being "stateless" and while those claims
@@ -153,26 +157,28 @@ seen is that there are a lot of different implementations each with its
 own warts and flaws; because changing is so painful, I can't actually
 use *any* of those alternatives.
 
-All of the password hashers I have reviewed have severe security versus
-usability tradeoffs. For example, LessPass has what seems to be a sound
-cryptographic implementation, but using it requires you to click on the
-icon, fill in the fields, click generate, and then copy the password
-into the field, which means at least four or five actions per password.
-The venerable [Password
-Hasher](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)

(Diff truncated)
fix dates
diff --git a/blog/2017-03-02-hashers-history.mdwn b/blog/2017-03-02-hashers-history.mdwn
new file mode 100644
index 0000000..2ed6264
--- /dev/null
+++ b/blog/2017-03-02-hashers-history.mdwn
@@ -0,0 +1,323 @@
+A short history of password hashers
+-----------------------------------
+
+Since the concept is so old, it may be useful to go over a
+short history of notable password hashers, before we go
+into issues specific to their implementation.
+
+[Nic Wolff](http://angel.net/~nic/passwd.current.html)
+[claims](https://news.ycombinator.com/item?id=12892655) to be the
+first to have written such a program, all the
+[way back in 2003](http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html). Back
+then the hashing algorithm was [MD5](https://en.wikipedia.org/wiki/MD5), although Wolff has now updated the
+algorithm to use [SHA-1](https://en.wikipedia.org/wiki/SHA-1) and still maintains his webpage for public
+use. Another ancient but unrelated implementation, is the Standford
+University Applied Cryptography's
+[pwdhash](https://crypto.stanford.edu/PwdHash) software. That
+implementation was
+[published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/)
+and unfortunately, that implementation was not updated and still uses
+MD5 as an hashing algorithm, but at least it uses
+[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)
+to generate tokens, which makes the use of
+[rainbow tables](https://en.wikipedia.org/wiki/Rainbow_table)
+impractical. Those implementations are the simplest
+password hashers: the inputs are simply the site URL and a
+password. So the algorithms are, basically, for Wolff's:
+
+    token = base64(SHA1(password + domain))
+
+And for [Standford's PwdHash](https://www.pwdhash.com/hashed-password.js):
+
+    token = base64(HMAC(MD5, password, domain)))
+
+Another unrelated implementation that is still around is
+[supergenpass](https://chriszarate.github.io/supergenpass/) is a
+bookmarklet that was
+[created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
+originally using MD5 as well but now supports SHA512 now although
+still
+[limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
+(which needlessly limits the entropy of the resulting password)
+and still
+[defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
+with
+[not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
+(10, when key derivation recommendations are more generally around 10
+000, so that it's slower to bruteforce).
+
+Note that Chris Zarate, the supergenpass author, actually
+credits Nic Wolff as the inspiration for his
+implementation. Supergenpass is still in active development and is
+available for the browser (as a
+[bookmarklet](https://chriszarate.github.io/supergenpass/)) or mobile
+(as an
+[webpage](https://chriszarate.github.io/supergenpass/mobile/)). Supergenpass
+allows you to modify the password length, but also add an extra
+profile secret which adds to the password and generates a personalized
+[identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
+prevent phishing but it also introduces the interesting protection,
+the profile-specific secret only found later in Password Hasher Plus. So the
+[Supergenpass algorithm](https://github.com/chriszarate/supergenpass-lib/blob/eb9ee92050813d498229bfe0e6ccbcb87124cf90/src/lib/generate.js#L32) looks something like this:
+
+    token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
+
+Another popular implementation is the Wijjo Password Hasher,
+[created around 2006](http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/).
+It was probably the first shipped as a
+[browser extension](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
+which greatly improved the security of the product as users didn't
+have to continually download the software on the fly. Wijjo's
+algorithm also improved on the above algorithms, as it uses HMAC-SHA1
+instead of plain SHA-1 or HMAC-MD5, which makes it harder to recover
+the plaintext. Password Hasher allows you to set different password
+policies (use digits, punctuation, mixed case, special characters and
+password length) and saves the site names it uses for future
+reference. It also happens that the Wijjo Password Hasher, in turn,
+took its inspiration on *different* project,
+[hashapass.com](http://www.hashapass.com/),
+[created in 2006](http://web.archive.org/web/20060702050519/http://www.hashapass.com/)
+and also based on
+HMAC-SHA-1. [Indeed](http://www.hashapass.com/en/cmd.html), hashapass
+"can easily be generated on almost any modern Unix-like system using
+the following command line pattern":
+
+    echo -n parameter \
+    | openssl dgst -sha1 -binary -hmac password \
+    | openssl enc -base64 \
+    | cut -c 1-8
+
+So the
+[algorithm](https://addons.mozilla.org/en-US/firefox/files/browse/140427/file/chrome/content/passhash-common.js#L298)
+here is obviously:
+
+    token = base64(HMAC(SHA1, password, domain + ":" + counter)))[:8]
+
+... although in the case of Password Hasher, there is a special
+routine that takes the token and inserts random characters in locations
+determined by the sum of the values of the characters in the token.
+
+Years later, in 2010, Eric Woodruff ported the Wijjo Password Hasher
+to Chrome and called it
+[Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd?hl=en).
+Like the original Password Hasher, the "plus" version also keeps those
+settings in the extension and uses HMAC-SHA-1 to generate the
+password, as it is designed to be backwards-compatible with the Wijjo
+Password Hasher. Woodruff did add one interesting feature: a
+profile-specific secret key that gets mixed in to create the security
+token, like what SuperGenPass does now. Stealing the master password is therefore not enough to
+generate tokens anymore. This solves one security concern with
+Password Hasher: an hostile page could watch your keystrokes and steal
+your master password and use it to derive passwords on other
+sites. Having a profile-specific secret key, not accessible to the
+site's Javascript works around that issue, but 
+typing the master password directly in the password field, while
+convenient, is just a bad idea, period. The final
+algorithm looks something like:
+
+    token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
+
+Honestly, that seems rather strange, but it's what I read from the
+source code, which is available only after decompressing the extension
+nowadays. I would have expected the simplest version:
+
+    token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain))
+
+(maybe this is for the extension attack?)
+
+Password Hasher Plus then takes the token and applies the same
+special character insertion routine as the Password Hasher.
+
+Last year, [Guillaume Vincent](http://guillaumevincent.com/) a french
+self-described "humanist and scuba diving fan" released the
+[lesspass](https://lesspass.com/) extension for Chrome, Firefox and
+Android. Lesspass introduces several interesting features. It
+is probably the first to include a
+[commandline version](https://github.com/lesspass/cli). It also
+[uses](https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4) a
+more robust key derivation algorithm
+([PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)) and takes into
+account the username on the site, allowing multi account support. The
+original release (version 1) used only 8192 rounds which is now
+[considered too low](http://stackoverflow.com/questions/6054082/recommended-of-iterations-when-using-pbkdf2-sha256). In the
+[bug report](https://github.com/lesspass/lesspass/issues/38) it was
+interesting to note that LessPass couldn't do the usual practice of
+running the key derivation for 1 second to determine the number of
+rounds needed as the results need to be deterministic. At first
+glance, the LessPass source code seems
+[clear and easy to read](https://github.com/lesspass/core/blob/master/src/v2.js)
+which is always a good sign, but of course, the devil
+is in the details. One key feature that is missing from Password Hasher
+Plus is the profile-specific seed, although it *should*
+be impossible, for a hostile web page 
+to steal keystrokes from a browser extension, as far as I know.
+
+The [algorithm][] then gets a little more interesting:
+
+    entropy = PBKDF2(SHA256, masterPassword, domain + username + counter, rounds, length)
+    where
+        rounds=10000
+        length=32
+        
+`entropy` is then used to pick characters to match the chosen profile.
+
+[algorithm]: https://github.com/lesspass/core/blob/24c339e/src/v2.js#L15
+
+(Confused by the PBKDF2 implementation here:
+https://github.com/lesspass/core/blob/master/src/pbkdf2.js - ImportKey
+doesn't support PBKDF2?? it's just something to extract key material?
+and then later, why AES-CTR??)
+
+There is also a
+[lesspass-specific character picking routing](https://github.com/lesspass/core/blob/24c339e/src/v2.js#L78)
+(ie. not base64, and different from the original Password Hasher
+algorithm).
+
+A review of password hashers would hardly be complete without
+mentioning the [Master Password](http://masterpasswordapp.com/) and its
+[elaborate algorithm](http://masterpasswordapp.com/algorithm.html). While the applications surrounding the project are
+not as refined (there is no web browser plugin and the
+[web interface](https://js.masterpasswordapp.com/) can't be easily
+turned into a bookmarklet), the algorithm has been well developed. Of all the
+password managers reviewed here, Master Password uses one of the
+strongest key derivation algorithms out there,
+[scrypt](https://en.wikipedia.org/wiki/Scrypt):
+
+    key = scrypt( password, salt, cost, size, parallelization, length )
+    where
+    salt = "com.lyndir.masterpassword" + len(username) + name
+    cost = 32768
+    size = 8
+    parallelization = 2
+    length = 64
+    entropy = hmac-sha256(key, "com.lyndir.masterpassword" + len(domain) + domain + counter )
+

(Diff truncated)
fix link again again
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
deleted file mode 100644
index d6ae982..0000000
--- a/blog/password-hashers.mdwn
+++ /dev/null
@@ -1,2 +0,0 @@
-[[!meta redir="2017-02-22-password-managers/"]]
-[[!tag redirection]]
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
new file mode 100644
index 0000000..d6ae982
--- /dev/null
+++ b/blog/password-managers.mdwn
@@ -0,0 +1,2 @@
+[[!meta redir="2017-02-22-password-managers/"]]
+[[!tag redirection]]

fix broken link - the url was published on twitter already
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
new file mode 100644
index 0000000..d6ae982
--- /dev/null
+++ b/blog/password-hashers.mdwn
@@ -0,0 +1,2 @@
+[[!meta redir="2017-02-22-password-managers/"]]
+[[!tag redirection]]

remove cruft
diff --git a/blog/2017-02-22-password-managers.mdwn b/blog/2017-02-22-password-managers.mdwn
index a96922d..878819c 100644
--- a/blog/2017-02-22-password-managers.mdwn
+++ b/blog/2017-02-22-password-managers.mdwn
@@ -162,7 +162,7 @@ likely involve setting up a private Git repository for your team,
 something which may not be accessible to the average Linux
 user. Nothing keeps you, however, from sharing the `~/.password-store`
 directory through another file sharing mechanism like (say)
-[Syncthing][] or [Dropbox][]).
+[Syncthing][] or [Dropbox][].
 
 [Syncthing]: https://syncthing.net/
 [Dropbox]: https://en.wikipedia.org/wiki/Dropbox_(service)
@@ -350,7 +350,7 @@ them accessible to machines. The general idea of those projects is to
 store secrets in a central server and send them directly to relevant
 services without human intervention. This way, passwords are not
 actually shared anymore, which is similar in spirit to the approach
-taken by centralized authentication systems like [Kerberos][]). If you
+taken by centralized authentication systems like [Kerberos][]. If you
 are looking at password management for teams, those projects may be
 worth a look.
 

fix some broken links
diff --git a/blog/2017-02-22-password-managers.mdwn b/blog/2017-02-22-password-managers.mdwn
index 34716f0..a96922d 100644
--- a/blog/2017-02-22-password-managers.mdwn
+++ b/blog/2017-02-22-password-managers.mdwn
@@ -165,7 +165,7 @@ directory through another file sharing mechanism like (say)
 [Syncthing][] or [Dropbox][]).
 
 [Syncthing]: https://syncthing.net/
-[Dropbox]: https://en.wikipedia.org/wiki/Dropbox_(service
+[Dropbox]: https://en.wikipedia.org/wiki/Dropbox_(service)
 
 You can use multiple distinct databases easily using the
 `PASSWORD_STORE_DIR` environment variable. For example, you could have
@@ -356,7 +356,7 @@ worth a look.
 
 [Vault]: https://www.vaultproject.io/
 [SFLvault]: http://sflvault.org/
-[Kerberos]: https://en.wikipedia.org/wiki/Kerberos_(protocol
+[Kerberos]: https://en.wikipedia.org/wiki/Kerberos_(protocol)
 
 Furthermore, some password managers that support auto-typing were
 found to be vulnerable to HTML injection attacks: if some third-party

fix path to article
diff --git a/blog/2017-02-22-password-managers.mdwn b/blog/2017-02-22-password-managers.mdwn
new file mode 100644
index 0000000..34716f0
--- /dev/null
+++ b/blog/2017-02-22-password-managers.mdwn
@@ -0,0 +1,409 @@
+[[!meta title="A look at password managers"]]
+[[!meta date="2017-02-15T12:00:00-0500"]]
+[[!meta updated="2017-02-22T19:49:36-0500"]]
+
+[[!toc startlevel=2]]
+
+As we noted in an
+[[earlier article|blog/2017-02-18-passwords-entropy]], passwords are a
+liability and we'd prefer to get rid of them, but the current reality
+is that we do use a plethora of passwords in our daily lives. This
+problem is especially acute for technology professionals, particularly
+system administrators, who have to manage a lot of different
+machines. But it also affects regular users who still use a large
+number of passwords, from their online bank to their favorite
+social-networking site. Despite the
+[remarkable memory capacity of the human brain][], humans are actually
+terrible at recalling even short sets of arbitrary characters with the
+precision needed for passwords.
+
+[remarkable memory capacity of the human brain]: https://www.scientificamerican.com/article/what-is-the-memory-capacity/
+
+Therefore humans [reuse passwords][], make them trivial or guessable,
+write them down on little paper notes and stick them on their screens,
+or just reset them by email every time. Our memory is undeniably
+failing us and we need help, which is where password managers come
+in. Password managers allow users to store an arbitrary number of
+passwords and just remember a single password to unlock them all.
+
+[reuse passwords]: https://xkcd.com/792/
+
+But there is a large variety of password managers out there, so which
+one should we be using? At my previous job, an inventory was done of
+about [40 different free-software password managers][] in different
+stages of development and of varying quality. So, obviously, this
+article will not be exhaustive, but instead focus on a smaller set of
+some well-known options that may be interesting to readers.
+
+[40 different free-software password managers]: https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison
+
+## KeePass: the popular alternative
+
+The most commonly used password-manager design pattern is to store
+passwords in a file that is encrypted and password-protected. The most
+popular free-software password manager of this kind is probably
+[KeePass][].
+
+[KeePass]: http://keepass.info/
+
+An important feature of KeePass is the ability to auto-type passwords in
+forms, most notably in web browsers. This feature makes KeePass really
+easy to use, especially considering it also supports global key bindings
+to access passwords. KeePass databases are designed for simultaneous
+access by multiple users, for example, using a shared network drive.
+
+KeePass has a graphical interface written in C\#, so it uses the Mono
+framework on Linux. A separate project, called [KeePassX][] is a
+clean-room implementation written in C++ using the Qt framework. Both
+support the [AES][] and [Twofish][] encryption algorithms, although
+KeePass recently added support for the [ChaCha20][] cipher. AES
+[key derivation][] is used to generate the actual encryption key for
+the database, but the latest release of KeePass also added using
+[Argon2][], which was the winner of the July 2015
+[password-hashing competition][]. Both programs are more or less
+equivalent, although the original KeePass seem to have more features
+in general.
+
+[KeePassX]: https://www.keepassx.org/
+[AES]: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
+[Twofish]: https://en.wikipedia.org/wiki/Twofish
+[ChaCha20]: https://en.wikipedia.org/wiki/ChaCha20
+[key derivation]: http://keepass.info/help/base/security.html#secdictprotect
+[Argon2]: https://en.wikipedia.org/wiki/Argon2
+[password-hashing competition]: https://password-hashing.net/
+
+The KeePassX project has recently been forked into another project now
+called [KeePassXC][] that implements a set of new
+features that are present in KeePass but missing from KeePassX like:
+
+[KeePassXC]: https://keepassxc.org/
+
+* auto-type on Linux, Mac OS, and Windows
+* database merging — which allows multi-user support
+* using the web site's favicon in the interface
+
+So far, the maintainers of KeePassXC seem to be open to
+[re-merging the project][] "*if the original maintainer of KeePassX in
+the future will be more active and will accept our merge and
+changes*". I can confirm that, at the time of writing, the original
+[KeePassX project][] now has 79 pending pull requests and only one
+pull request was merged since the last release, which was 2.0.3 in
+September 2016.
+
+[re-merging the project]: https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934
+[KeePassX project]: https://github.com/keepassx/keepassx
+
+While KeePass and derivatives allow multiple users to access the same
+database through the merging process, they do not support multi-party
+access to a single database. This may be a limiting factor for larger
+organizations, where you may need, for example, a different password set
+for different technical support team levels. The solution in this case
+is to use separate databases for each team, with each team using a
+different shared secret.
+
+## Pass: the standard password manager?
+
+I am currently using [password-store][], or pass, as a password
+manager. It aims to be "*the standard Unix password manager*". Pass is
+a GnuPG-based password manager that features a surprising number of
+features given its small size:
+
+[password-store]: https://www.passwordstore.org/
+
+ * copy-paste support
+ * Git integration
+ * multi-user/group support
+ * pluggable extensions (in the upcoming 1.7 release)
+
+The command-line interface is simple to use and intuitive. The
+following, will, for example, create a pass repository, a 20 character
+password for your LWN account and copy it to the clipboard:
+
+        $ pass init
+        $ pass generate -c lwn 20
+
+The main issue with pass is that it doesn't encrypt the *name* of
+those entries: if someone were to compromise my machine, they could
+easily see which sites I have access to simply by listing the
+passwords stored in `~/.password-store`. This is a deliberate design
+decision by the upstream project, as [stated][] by a mailing list
+participant, Allan Odgaard:
+
+[stated]: https://lists.zx2c4.com/pipermail/password-store/2014-June/001001.html
+
+> Using a single file per item has the advantage of shell completion,
+> using version control, browse, move and rename the items in a file
+> browser, edit them in a regular editor (that does GPG, or manually
+> run GPG first), etc.
+
+Odgaard goes on to point out that there are alternatives that do encrypt
+the entire database (including the site names) if users really need that
+feature.
+
+Furthermore, there is a [tomb plugin][] for pass that encrypts the
+password store in a [LUKS][] container (called a "[tomb][]"), although
+it requires explicitly opening and closing the container, which makes
+it only marginally better than using full disk encryption
+system-wide. One could also argue that password file names do not hold
+secret information, only the site name and username, perhaps, and that
+doesn't require secrecy. I do believe those should be kept secret,
+however, as they could be used to discover (or prove) which sites you
+have access to and then used to perform other attacks. One could draw
+a parallel with the SSH `known_hosts` file, which used to be plain
+text but is now hashed so that hosts are more difficult to discover.
+
+[tomb plugin]: https://github.com/roddhjav/pass-tomb
+[LUKS]: https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup
+[tomb]: https://github.com/dyne/Tomb
+
+Also, sharing a database for multi-user support will require some sort
+of file-sharing mechanism. Given the integrated Git support, this will
+likely involve setting up a private Git repository for your team,
+something which may not be accessible to the average Linux
+user. Nothing keeps you, however, from sharing the `~/.password-store`
+directory through another file sharing mechanism like (say)
+[Syncthing][] or [Dropbox][]).
+
+[Syncthing]: https://syncthing.net/
+[Dropbox]: https://en.wikipedia.org/wiki/Dropbox_(service
+
+You can use multiple distinct databases easily using the
+`PASSWORD_STORE_DIR` environment variable. For example, you could have
+a shell alias to use a different repository for your work passwords
+with:
+
+        alias work-pass="PASSWORD_STORE_DIR=~/work-passwords pass"
+
+Group support comes from a clever use of the GnuPG multiple-recipient
+encryption support. You simply have to specify multiple OpenPGP
+identities when initializing the repository, which also works in
+subdirectories:
+
+        $ pass init -p Ateam me@example.com joelle@example.com
+        mkdir: created directory '/home/me/.password-store/Ateam'
+        Password store initialized for me@example.com, joelle@example.com
+        [master 0e3dbe7] Set GPG id to me@example.com, joelle@example.com.
+         1 file changed, 2 insertions(+)
+         create mode 100644 Ateam/.gpg-id
+
+The above will configure pass to encrypt the passwords in the `Ateam`
+directory for me@example.com and joelle@example.com. Pass depends on
+GnuPG to do the right thing when encrypting files and how those
+identities are treated is entirely delegated to GnuPG's default
+configuration. This could lead to [problems][] if
+arbitrary keys can be injected into your key ring, which could confuse

(fichier de différences tronqué)
fix link to previous article
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 67fe64f..34716f0 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -4,18 +4,19 @@
 
 [[!toc startlevel=2]]
 
-As we noted in an [earlier article][], passwords are a liability and
-we'd prefer to get rid of them, but the current reality is that we do
-use a plethora of passwords in our daily lives. This problem is
-especially acute for technology professionals, particularly system
-administrators, who have to manage a lot of different machines. But it
-also affects regular users who still use a large number of passwords,
-from their online bank to their favorite social-networking
-site. Despite the [remarkable memory capacity of the human brain][],
-humans are actually terrible at recalling even short sets of arbitrary
-characters with the precision needed for passwords.
-
-[earlier article]: https://lwn.net/Articles/713806/
+As we noted in an
+[[earlier article|blog/2017-02-18-passwords-entropy]], passwords are a
+liability and we'd prefer to get rid of them, but the current reality
+is that we do use a plethora of passwords in our daily lives. This
+problem is especially acute for technology professionals, particularly
+system administrators, who have to manage a lot of different
+machines. But it also affects regular users who still use a large
+number of passwords, from their online bank to their favorite
+social-networking site. Despite the
+[remarkable memory capacity of the human brain][], humans are actually
+terrible at recalling even short sets of arbitrary characters with the
+precision needed for passwords.
+
 [remarkable memory capacity of the human brain]: https://www.scientificamerican.com/article/what-is-the-memory-capacity/
 
 Therefore humans [reuse passwords][], make them trivial or guessable,

final reformatting for blog
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 6662f09..67fe64f 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -2,43 +2,48 @@
 [[!meta date="2017-02-15T12:00:00-0500"]]
 [[!meta updated="2017-02-22T19:49:36-0500"]]
 
-[[!toc levels=2]]
+[[!toc startlevel=2]]
 
-As we noted in an [earlier article](/Articles/713806/), passwords are a
-liability and we'd prefer to get rid of them, but the current reality is
-that we do use a plethora of passwords in our daily lives. This problem
-is especially acute for technology professionals, particularly system
+As we noted in an [earlier article][], passwords are a liability and
+we'd prefer to get rid of them, but the current reality is that we do
+use a plethora of passwords in our daily lives. This problem is
+especially acute for technology professionals, particularly system
 administrators, who have to manage a lot of different machines. But it
 also affects regular users who still use a large number of passwords,
-from their online bank to their favorite social-networking site. Despite
-the [remarkable memory capacity of the human
-brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
+from their online bank to their favorite social-networking
+site. Despite the [remarkable memory capacity of the human brain][],
 humans are actually terrible at recalling even short sets of arbitrary
 characters with the precision needed for passwords.
 
-Therefore humans [reuse passwords](https://xkcd.com/792/), make them
-trivial or guessable, write them down on little paper notes and stick
-them on their screens, or just reset them by email every time. Our
-memory is undeniably failing us and we need help, which is where
-password managers come in. Password managers allow users to store an
-arbitrary number of passwords and just remember a single password to
-unlock them all.
+[earlier article]: https://lwn.net/Articles/713806/
+[remarkable memory capacity of the human brain]: https://www.scientificamerican.com/article/what-is-the-memory-capacity/
+
+Therefore humans [reuse passwords][], make them trivial or guessable,
+write them down on little paper notes and stick them on their screens,
+or just reset them by email every time. Our memory is undeniably
+failing us and we need help, which is where password managers come
+in. Password managers allow users to store an arbitrary number of
+passwords and just remember a single password to unlock them all.
+
+[reuse passwords]: https://xkcd.com/792/
 
 But there is a large variety of password managers out there, so which
 one should we be using? At my previous job, an inventory was done of
-about [40 different free-software password
-managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
-in different stages of development and of varying quality. So,
-obviously, this article will not be exhaustive, but instead focus on a
-smaller set of some well-known options that may be interesting to
-readers.
+about [40 different free-software password managers][] in different
+stages of development and of varying quality. So, obviously, this
+article will not be exhaustive, but instead focus on a smaller set of
+some well-known options that may be interesting to readers.
+
+[40 different free-software password managers]: https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison
 
-#### KeePass: the popular alternative
+## KeePass: the popular alternative
 
 The most commonly used password-manager design pattern is to store
 passwords in a file that is encrypted and password-protected. The most
 popular free-software password manager of this kind is probably
-[KeePass](http://keepass.info/).
+[KeePass][].
+
+[KeePass]: http://keepass.info/
 
 An important feature of KeePass is the ability to auto-type passwords in
 forms, most notably in web browsers. This feature makes KeePass really
@@ -47,38 +52,45 @@ to access passwords. KeePass databases are designed for simultaneous
 access by multiple users, for example, using a shared network drive.
 
 KeePass has a graphical interface written in C\#, so it uses the Mono
-framework on Linux. A separate project, called
-[KeePassX](https://www.keepassx.org/) is a clean-room implementation
-written in C++ using the Qt framework. Both support the
-[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and
-[Twofish](https://en.wikipedia.org/wiki/Twofish) encryption algorithms,
-although KeePass recently added support for the
-[ChaCha20](https://en.wikipedia.org/wiki/ChaCha20) cipher. AES [key
-derivation](http://keepass.info/help/base/security.html#secdictprotect)
-is used to generate the actual encryption key for the database, but the
-latest release of KeePass also added using
-[Argon2](https://en.wikipedia.org/wiki/Argon2), which was the winner of
-the July 2015 [password-hashing
-competition](https://password-hashing.net/). Both programs are more or
-less equivalent, although the original KeePass seem to have more
-features in general.
+framework on Linux. A separate project, called [KeePassX][] is a
+clean-room implementation written in C++ using the Qt framework. Both
+support the [AES][] and [Twofish][] encryption algorithms, although
+KeePass recently added support for the [ChaCha20][] cipher. AES
+[key derivation][] is used to generate the actual encryption key for
+the database, but the latest release of KeePass also added using
+[Argon2][], which was the winner of the July 2015
+[password-hashing competition][]. Both programs are more or less
+equivalent, although the original KeePass seem to have more features
+in general.
+
+[KeePassX]: https://www.keepassx.org/
+[AES]: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard
+[Twofish]: https://en.wikipedia.org/wiki/Twofish
+[ChaCha20]: https://en.wikipedia.org/wiki/ChaCha20
+[key derivation]: http://keepass.info/help/base/security.html#secdictprotect
+[Argon2]: https://en.wikipedia.org/wiki/Argon2
+[password-hashing competition]: https://password-hashing.net/
 
 The KeePassX project has recently been forked into another project now
-called [KeePassXC](https://keepassxc.org/) that implements a set of new
+called [KeePassXC][] that implements a set of new
 features that are present in KeePass but missing from KeePassX like:
 
--   auto-type on Linux, Mac OS, and Windows
--   database merging — which allows multi-user support
--   using the web site's favicon in the interface
+[KeePassXC]: https://keepassxc.org/
+
+* auto-type on Linux, Mac OS, and Windows
+* database merging — which allows multi-user support
+* using the web site's favicon in the interface
 
-So far, the maintainers of KeePassXC seem to be open to [re-merging the
-project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
-"<span>if the original maintainer of KeePassX in the future will be more
-active and will accept our merge and changes</span>". I can confirm
-that, at the time of writing, the original [KeePassX
-project](https://github.com/keepassx/keepassx) now has 79 pending pull
-requests and only one pull request was merged since the last release,
-which was 2.0.3 in September 2016.
+So far, the maintainers of KeePassXC seem to be open to
+[re-merging the project][] "*if the original maintainer of KeePassX in
+the future will be more active and will accept our merge and
+changes*". I can confirm that, at the time of writing, the original
+[KeePassX project][] now has 79 pending pull requests and only one
+pull request was merged since the last release, which was 2.0.3 in
+September 2016.
+
+[re-merging the project]: https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934
+[KeePassX project]: https://github.com/keepassx/keepassx
 
 While KeePass and derivatives allow multiple users to access the same
 database through the merging process, they do not support multi-party
@@ -88,17 +100,19 @@ for different technical support team levels. The solution in this case
 is to use separate databases for each team, with each team using a
 different shared secret.
 
-#### Pass: the standard password manager?
+## Pass: the standard password manager?
+
+I am currently using [password-store][], or pass, as a password
+manager. It aims to be "*the standard Unix password manager*". Pass is
+a GnuPG-based password manager that features a surprising number of
+features given its small size:
 
-I am currently using [password-store](https://www.passwordstore.org/),
-or pass, as a password manager. It aims to be "<span>the standard Unix
-password manager</span>". Pass is a GnuPG-based password manager that
-features a surprising number of features given its small size:
+[password-store]: https://www.passwordstore.org/
 
--   copy-paste support
--   Git integration
--   multi-user/group support
--   pluggable extensions (in the upcoming 1.7 release)
+ * copy-paste support
+ * Git integration
+ * multi-user/group support
+ * pluggable extensions (in the upcoming 1.7 release)
 
 The command-line interface is simple to use and intuitive. The
 following, will, for example, create a pass repository, a 20 character
@@ -107,54 +121,55 @@ password for your LWN account and copy it to the clipboard:
         $ pass init
         $ pass generate -c lwn 20
 
-The main issue with pass is that it doesn't encrypt the *name* of those
-entries: if someone were to compromise my machine, they could easily see
-which sites I have access to simply by listing the passwords stored in
-`~/.password-store`. This is a deliberate design decision by the
-upstream project, as
-[stated](https://lists.zx2c4.com/pipermail/password-store/2014-June/001001.html)
-by a mailing list participant, Allan Odgaard:
+The main issue with pass is that it doesn't encrypt the *name* of
+those entries: if someone were to compromise my machine, they could
+easily see which sites I have access to simply by listing the
+passwords stored in `~/.password-store`. This is a deliberate design
+decision by the upstream project, as [stated][] by a mailing list
+participant, Allan Odgaard:
 
-<div class="BigQuote">
+[stated]: https://lists.zx2c4.com/pipermail/password-store/2014-June/001001.html
 
-Using a single file per item has the advantage of shell completion,

(fichier de différences tronqué)
publish managers article
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index ce5d80c..6662f09 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -1,5 +1,8 @@
-A look at password managers
-===========================
+[[!meta title="A look at password managers"]]
+[[!meta date="2017-02-15T12:00:00-0500"]]
+[[!meta updated="2017-02-22T19:49:36-0500"]]
+
+[[!toc levels=2]]
 
 As we noted in an [earlier article](/Articles/713806/), passwords are a
 liability and we'd prefer to get rid of them, but the current reality is
@@ -363,3 +366,11 @@ emerging as a convenient solution that could possibly replace
 traditional password managers as users switch from generic computing
 platforms to cloud-based infrastructure. We will cover password hashers
 and the major security challenges they pose in a future article.
+
+> *Note: this article [first appeared][] in the
+> [Linux Weekly News][].*
+
+[first appeared]: https://lwn.net/Articles/714473/
+[Linux Weekly News]: http://lwn.net/
+
+[[!tag debian-planet debian passwords lwn geek security crypto]]

final review from LWN
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 1086656..472bf20 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -112,8 +112,8 @@ A password is now ciphertext, not a block of line noise. Every time you
 transmit it, you are giving away potential clues of use to an attacker.
 \[...\]
 You only have one password for all the sites, really, underneath, and
-it's your secret key. If it's broken, it's now a skeleton-key and
-[all your passwords are compromised].
+it's your secret key. If it's broken, it's now a skeleton-key \[...\]
+
 </div>
 
 Newer implementations like LessPass and Master Password fix this by
@@ -145,21 +145,20 @@ online. At this point, a key benefit of the password hasher approach
 manager.
 
 Another issue with password hashers is choosing the right one from the
-start, because changing software generally means changing the
-algorithm, and therefore changing passwords everywhere. If there was
-this well-established solution that would be recognized as a solid
-cryptographic solution by the community, I would feel more
-confident. But what I have seen is that there are a *lot* of different
-implementations with each their own warts and flaws and because
-changing is so painful, I can't actually use *any* of those
-alternatives.
-
-All of the password hashers I have reviewd have severe
-security versus usability tradeoffs. For example, LessPass has what
-seems to be a sound cryptographic implementation, but using it requires
-you to click on the icon, fill in the fields, click generate, and then
-copy the password into the field, which means at least four or five
-actions per password. The venerable [Password
+start, because changing software generally means changing the algorithm,
+and therefore changing passwords everywhere. If there was a
+well-established program that was be recognized as a solid cryptographic
+solution by the community, I would feel more confident. But what I have
+seen is that there are a lot of different implementations each with its
+own warts and flaws; because changing is so painful, I can't actually
+use *any* of those alternatives.
+
+All of the password hashers I have reviewed have severe security versus
+usability tradeoffs. For example, LessPass has what seems to be a sound
+cryptographic implementation, but using it requires you to click on the
+icon, fill in the fields, click generate, and then copy the password
+into the field, which means at least four or five actions per password.
+The venerable [Password
 Hasher](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
 is much easier to use, but it makes you type the master password
 directly in the site's password form, so hostile sites can simply use
@@ -182,8 +181,7 @@ multiple sites, you need to choose (and remember) what label you used
 when signing in. Did I sign in on stackoverflow.com? Or was it
 stackexchange.com?
 
-Also, as mentioned in the [previous
-article](https://lwn.net/Articles/714473/) about password managers,
+Also, as mentioned in the previous article about password managers,
 web-based password managers have serious security flaws. Since more than
 a few password hashers are implemented using bookmarklets, they bring
 all of those [serious
@@ -201,13 +199,13 @@ already](https://tools.ietf.org/html/rfc6151#ref-COYI2006) and while
 those do not allow an attacker to recover the full master password yet
 (especially not with HMAC-MD5), I would not recommend anyone use MD5 in
 anything at this point, especially if changing that algorithm later is
-hard. Some hashers (like Password Hasher and Password Plus) use a
-single round of HMAC [SHA-1](https://en.wikipedia.org/wiki/SHA-1) to derive
-a token from the password, whereas, for example, WPA2 (standardized
-in 2004) uses 4096 iterations of HMAC-SHA1. A recent US National
-Institute of Standards and Technology (NIST) report also
+hard. Some hashers (like Password Hasher and Password Plus) use a a
+*single* round of [SHA-1](https://en.wikipedia.org/wiki/SHA-1) to derive
+a token from a password; WPA2 (standardized in 2004) uses 4096
+iterations of HMAC-SHA1. A recent US National Institute of Standards and
+Technology (NIST) report also
 [recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-verifiers)
-"at least 10,000 iterations of the hash function".
+"<span>at least 10,000 iterations of the hash function</span>".
 
 #### Conclusion
 

another review with LWN
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 87686d9..1086656 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -5,16 +5,21 @@ In previous articles, we have looked at [how to generate
 passwords](https://lwn.net/Articles/713806/) and did a [review of
 various password managers](https://lwn.net/Articles/714473/). There is,
 however, a third way of managing passwords other than remembering them
-or encrypting them in a "vault": what I call "password hashing". You may
-know these as "deterministic or stateless password managers" but I find
-the "password manager" phrase to be confusing because it doesn't
-actually store any passwords.
-
-I do not think password hashers represent a good security tradeoff so I
-generally do not recommend their use, unless you really do not have
-access to reliable storage that you can access readily.
-
-In this text, I use the word "password" for a random string used to
+or encrypting them in a "vault", which is what I call "password
+hashing".
+
+A password hasher generates site-specific passwords from a single master
+password using a cryptographic hash function. It thus allows a user to
+have a unique and secure password for every site they use while
+requiring no storage; they need only to remember a single password. You
+may know these as "deterministic or stateless password managers" but I
+find the "password manager" phrase to be confusing because a hasher
+doesn't actually store any passwords. I do not think password hashers
+represent a good security tradeoff so I generally do not recommend their
+use, unless you really do not have access to reliable storage that you
+can access readily.
+
+In this article, I use the word "password" for a random string used to
 unlock things, but "token" to represent a generated random string that
 the user doesn't need to remember. The input to a password hasher is a
 password with some site-specific context and the output from a password
@@ -22,14 +27,12 @@ hasher is a token.
 
 #### What is a password hasher?
 
-A password hasher is a piece of software that turns a single master
-password into multiple passwords by turning the master password and a
-label (generally the host name) into a site-specific password using some
-cryptographic functions. To change the generated password, the user can
-modify the label, for example by appending a number. Some password
-hashers also have different settings to generate tokens of different
-lengths or compositions (symbols or not, etc.) to accommodate different
-site-specific password policies.
+A password hasher uses the master password and a label (generally the
+host name) to generate the site-specific password. To change the
+generated password, the user can modify the label, for example by
+appending a number. Some password hashers also have different settings
+to generate tokens of different lengths or compositions (symbols or not,
+etc.) to accommodate different site-specific password policies.
 
 The whole concept of password hashers relies on the concept of one-way
 [cryptographic hash
@@ -96,8 +99,8 @@ or seeds (like a profile-specific secret) makes those attacks much
 harder, especially if the seed is long enough to make brute-force
 attacks infeasible. (Unfortunately, in the case of [Password Hasher
 Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd),
-the seed is derived from `Math.random()` calls which is [not considered
-cryptographically
+the seed is derived from `Math.random()` calls, which are [not
+considered cryptographically
 secure](http://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure).)
 
 Basically, as stated by Julian Morrison in [this
@@ -115,9 +118,9 @@ it's your secret key. If it's broken, it's now a skeleton-key and
 
 Newer implementations like LessPass and Master Password fix this by
 using reasonable key derivation algorithms (PBKDF2 and scrypt,
-respectively), but who knows how long those will hold? To give a
-concrete example, if you would like to use the new winner of the
-password hashing competition
+respectively) that are more resistant to offline cracking attacks, but
+who knows how long those will hold? To give a concrete example, if you
+would like to use the new winner of the password hashing competition
 ([Argon2](https://en.wikipedia.org/wiki/Argon2)) in your password
 manager, you can patch the program (or wait for an update) and
 re-encrypt your database. With a password hasher, it's not so easy:
@@ -142,35 +145,35 @@ online. At this point, a key benefit of the password hasher approach
 manager.
 
 Another issue with password hashers is choosing the right one from the
-start, because changing software generally means changing the algorithm,
-and therefore changing passwords everywhere. If there was this
-well-established solution that would be recognized as a solid
+start, because changing software generally means changing the
+algorithm, and therefore changing passwords everywhere. If there was
+this well-established solution that would be recognized as a solid
 cryptographic solution by the community, I would feel more
 confident. But what I have seen is that there are a *lot* of different
 implementations with each their own warts and flaws and because
-changing is so painful, I can't actually use *any* of those alternatives.
-
-All of the password hashers I have reviewed have severe security
-versus usability tradeoffs. For example, LessPass has what seems to be
-a sound cryptographic implementation, but using it requires you to
-click on the icon, fill in the fields, click generate, and then copy
-the password into the field, which means at least four or five actions
-per password. The venerable
-[Password Hasher](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
-is way easier to use, but makes you type the master password directly
-in the site's password form, so hostile sites can simply use
-Javascript to sniff the master password while it is typed. While there
+changing is so painful, I can't actually use *any* of those
+alternatives.
+
+All of the password hashers I have reviewd have severe
+security versus usability tradeoffs. For example, LessPass has what
+seems to be a sound cryptographic implementation, but using it requires
+you to click on the icon, fill in the fields, click generate, and then
+copy the password into the field, which means at least four or five
+actions per password. The venerable [Password
+Hasher](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
+is much easier to use, but it makes you type the master password
+directly in the site's password form, so hostile sites can simply use
+JavaScript to sniff the master password while it is typed. While there
 are workarounds implemented in Password Hasher Plus (the
-profile-specific secret), both tools are more or less abandoned
-now. The [Password Hasher homepage](http://wijjo.com/passhash/),
-linked from the extension page, is now a 404. Password Hasher Plus
-hasn't seen a release in over a year and there is no space for
-collaborating on the software — the homepage is simply the author's
-Google+ page with no information on the project.  I couldn't actually
-find the source online and had to download the Chrome extension by
-hand to review the source code. Software abandonment is a serious
-issue for every project out there, but I would argue that it is
-especially severe for password hashers.
+profile-specific secret), both tools are more or less abandoned now. The
+[Password Hasher homepage](http://wijjo.com/passhash/), linked from the
+extension page, is now a 404. Password Hasher Plus hasn't seen a release
+in over a year and there is no space for collaborating on the software —
+the homepage is simply the author's Google+ page with no information on
+the project. I couldn't actually find the source online and had to
+download the Chrome extension by hand to review the source code.
+Software abandonment is a serious issue for every project out there, but
+I would argue that it is especially severe for password hashers.
 
 Furthermore, I have had difficulty using password hashers in unified
 login environments like Wikipedia's or StackExchange's single-sign-on
@@ -198,14 +201,11 @@ already](https://tools.ietf.org/html/rfc6151#ref-COYI2006) and while
 those do not allow an attacker to recover the full master password yet
 (especially not with HMAC-MD5), I would not recommend anyone use MD5 in
 anything at this point, especially if changing that algorithm later is
-hard. Password Hasher and Password Hasher Plus use a JavaScript
-`hmac_sha1()` function picked from [some site on the
-internet](http://pajhome.org.uk/crypt/md5/) to derive tokens. While the
-HMAC secret adds a good layer of security, using a *single* round of
-[SHA-1](https://en.wikipedia.org/wiki/SHA-1) to derive a token from a
-password is generally considered weak; WPA2 (standardized in 2004) uses
-4096 iterations of HMAC-SHA1. A recent US National Institute of
-Standards and Technology (NIST) report also
+hard. Some hashers (like Password Hasher and Password Plus) use a
+single round of HMAC [SHA-1](https://en.wikipedia.org/wiki/SHA-1) to derive
+a token from the password, whereas, for example, WPA2 (standardized
+in 2004) uses 4096 iterations of HMAC-SHA1. A recent US National
+Institute of Standards and Technology (NIST) report also
 [recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-verifiers)
 "at least 10,000 iterations of the hash function".
 

rephrase one bit and bring back the nasty quote, but paraphrased
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index bb8e089..87686d9 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -109,8 +109,8 @@ A password is now ciphertext, not a block of line noise. Every time you
 transmit it, you are giving away potential clues of use to an attacker.
 \[...\]
 You only have one password for all the sites, really, underneath, and
-it's your secret key.
-
+it's your secret key. If it's broken, it's now a skeleton-key and
+[all your passwords are compromised].
 </div>
 
 Newer implementations like LessPass and Master Password fix this by
@@ -143,26 +143,34 @@ manager.
 
 Another issue with password hashers is choosing the right one from the
 start, because changing software generally means changing the algorithm,
-and therefore changing passwords everywhere. All of them have severe
-security versus usability tradeoffs. For example, LessPass has what
-seems to be a sound cryptographic implementation, but using it requires
-you to click on the icon, fill in the fields, click generate, and then
-copy the password into the field, which means at least four or five
-actions per password. The venerable [Password
-Hasher](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
-is way easier to use, but makes you type the master password directly in
-the site's password form, so hostile sites can simply use Javascript to
-sniff the master password while it is typed. While there are workarounds
-implemented in Password Hasher Plus (the profile-specific secret), both
-tools are more or less abandoned now. The [Password Hasher
-homepage](http://wijjo.com/passhash/), linked from the extension page,
-is now a 404. Password Hasher Plus hasn't seen a release in over a year
-and there is no space for collaborating on the software — the homepage
-is simply the author's Google+ page with no information on the project.
-I couldn't actually find the source online and had to download the
-Chrome extension by hand to review the source code. Software abandonment
-is a serious issue for every project out there, but I would argue that
-it is especially severe for password hashers.
+and therefore changing passwords everywhere. If there was this
+well-established solution that would be recognized as a solid
+cryptographic solution by the community, I would feel more
+confident. But what I have seen is that there are a *lot* of different
+implementations with each their own warts and flaws and because
+changing is so painful, I can't actually use *any* of those alternatives.
+
+All of the password hashers I have reviewed have severe security
+versus usability tradeoffs. For example, LessPass has what seems to be
+a sound cryptographic implementation, but using it requires you to
+click on the icon, fill in the fields, click generate, and then copy
+the password into the field, which means at least four or five actions
+per password. The venerable
+[Password Hasher](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
+is way easier to use, but makes you type the master password directly
+in the site's password form, so hostile sites can simply use
+Javascript to sniff the master password while it is typed. While there
+are workarounds implemented in Password Hasher Plus (the
+profile-specific secret), both tools are more or less abandoned
+now. The [Password Hasher homepage](http://wijjo.com/passhash/),
+linked from the extension page, is now a 404. Password Hasher Plus
+hasn't seen a release in over a year and there is no space for
+collaborating on the software — the homepage is simply the author's
+Google+ page with no information on the project.  I couldn't actually
+find the source online and had to download the Chrome extension by
+hand to review the source code. Software abandonment is a serious
+issue for every project out there, but I would argue that it is
+especially severe for password hashers.
 
 Furthermore, I have had difficulty using password hashers in unified
 login environments like Wikipedia's or StackExchange's single-sign-on

note about unshare
diff --git a/software/debian-development.mdwn b/software/debian-development.mdwn
index e119b4d..0ff14c0 100644
--- a/software/debian-development.mdwn
+++ b/software/debian-development.mdwn
@@ -663,6 +663,16 @@ because of missing dependency, so you need to also run `apt-get
 install -f`.
 
 [netcat]: https://en.wikipedia.org/wiki/Netcat
+
+Another option is to use the "unshare" command, which launches another
+command in a different namespace:
+
+    sudo unshare -i -m -p -u -f chroot /path/mountpoint qemu-arm-static /bin/bash
+
+This can reuse chroots previously created for cowbuilder, but the
+filesystem separation works only if /path/mountpoint is really a
+different mountpoint. Otherwise changes in the filesystem affect the
+parent host, in which case you can just copy over the chroot.
 """]]
 
 There are a *lot* of different virtualization solutions you can use

add future work
diff --git a/blog/2015-12-14-yubikey-howto.mdwn b/blog/2015-12-14-yubikey-howto.mdwn
index 6e0722d..058f7b5 100644
--- a/blog/2015-12-14-yubikey-howto.mdwn
+++ b/blog/2015-12-14-yubikey-howto.mdwn
@@ -457,4 +457,47 @@ The workaround documented there is to add `disable-ccid` to
 `~/.gnupg/scdaemon.conf`. The proper fix is to uninstall `pcscd` and
 make sure you have the appropriate udev rule, as mentioned earlier.
 
+Future work
+===========
+
+I may try to put more stuff (like my workstation) on 2FA. Right now
+I'm using the [once](https://0xacab.org/guido/once) package to fake
+2FA, but it's basically useless because I'm also storing the passwords
+in OpenPGP-encrypted files. This is not really a 2FA, except maybe for
+timing issues.
+
+To use more OTP, I can't really use OATH, because there's a limited
+set of tokens I can configure there. One way around this would be to
+use U2F, which I originally described as "for the web", but for which
+there's an actually quite solid
+[pam package](https://packages.debian.org/sid/libpam-u2f). Plus this
+would enable more robust 2FA in a bunch of places. This would mean I
+could lose access if i lose the token, however, so I may need to think
+about having a backup token. Maybe recovery codes are all I need.
+
+I could also move *more* key material in the device. Right now, I use
+only for authentication, but there's no reason why (other than
+backups) than I wouldn't use it for a certification key. Encryption is
+tricker, because those keys can be
+[slow](http://www.fsij.org/gnuk/how-fast-gnuk-token.html), which
+doesn't matter for signing stuff, but decryption happens way more
+often and on larger things.
+
+I should also look at alternative device. The
+[FST-01](http://wiki.seeed.cc/FST-01/) looks a little bare-metal, but
+it's actually pretty solid, and can be encased in
+[plastic cray](https://www.fsij.org/gnuk/customizing-2017.html),
+[origami](http://www.fsij.org/gnuk/craftwork-fst-01.html),
+[string](http://www.fsij.org/gnuk/customizing-gnuk-token.html), an
+[eraser](http://www.fsij.org/gnuk/mono-the-eraser-case.html) and so
+many cute other ideas. A friend just took the cover off another USB
+key and used that.
+
+The FST-01 is just hardware though, you need to deploy the
+[Gnuk](http://www.fsij.org/doc-gnuk/) to it to get the usual
+signing/encryption primitives going. Which is cool because it means
+the same device can also serve other purposes, like a TRNG (the
+[NeuG](http://www.gniibe.org/memo/development/gnuk/rng/neug.html)). (Why
+do all those software project names sound like troll names? :)
+
 [[!tag debian-planet geek software debian hacking security crypto]]

privileged extension is a thing in f-droid now
diff --git a/hardware/phone/htc-one-s.mdwn b/hardware/phone/htc-one-s.mdwn
index ed48982..4d4e0ab 100644
--- a/hardware/phone/htc-one-s.mdwn
+++ b/hardware/phone/htc-one-s.mdwn
@@ -940,6 +940,10 @@ Future work
   routes inside the house without having to go outside for the GPS to
   get a fix.</del> Removing gapps made that work well, along with the
   fake GSM services described above.
+* Install F-Droid using the [privileged extension][] so we don't have
+  to tick the nasty "allow 3rd party APKs"
+
+[privileged extension]: https://gitlab.com/fdroid/privileged-extension
 
 [Yalp Store]: https://github.com/yeriomin/YalpStore
 

remove potentially homophobic, rapist quote
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 1670c64..bb8e089 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -109,8 +109,7 @@ A password is now ciphertext, not a block of line noise. Every time you
 transmit it, you are giving away potential clues of use to an attacker.
 \[...\]
 You only have one password for all the sites, really, underneath, and
-it's your secret key. If it's broken, it's now a skeleton-key and your
-digital ass is theirs.
+it's your secret key.
 
 </div>
 

first review from LWN
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 7bc60aa..1670c64 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -1,112 +1,118 @@
 The case against password hashers
 =================================
 
-In previous articles, we have covered
-[how to generate passwords](https://lwn.net/Articles/713806/) and a
-[review of various password managers](https://lwn.net/Articles/714473/). There
-is, however, a third way of managing passwords other than remembering
-them or encrypting them in a "vault", and that is what I call
-"password hashing". You may know those as "deterministic or stateless
-password managers" but I find the "password manager" denomination to
-be confusing because it doesn't actually store any password.
-
-I do not think password hashers represent a good security tradeoff so
-I generally do not recommend their use, unless you really do not have
-access to reliable storage you can access readily.
+In previous articles, we have looked at [how to generate
+passwords](https://lwn.net/Articles/713806/) and did a [review of
+various password managers](https://lwn.net/Articles/714473/). There is,
+however, a third way of managing passwords other than remembering them
+or encrypting them in a "vault": what I call "password hashing". You may
+know these as "deterministic or stateless password managers" but I find
+the "password manager" phrase to be confusing because it doesn't
+actually store any passwords.
+
+I do not think password hashers represent a good security tradeoff so I
+generally do not recommend their use, unless you really do not have
+access to reliable storage that you can access readily.
 
 In this text, I use the word "password" for a random string used to
 unlock things, but "token" to represent a generated random string that
-the user doesn't need to remember. The input of a password hasher is a
-password with some site-specific context and the output of a password
+the user doesn't need to remember. The input to a password hasher is a
+password with some site-specific context and the output from a password
 hasher is a token.
 
-What is a password hasher?
---------------------------
+#### What is a password hasher?
 
 A password hasher is a piece of software that turns a single master
 password into multiple passwords by turning the master password and a
-label (generally the hostname) into a site-specific password using
-some cryptographic functions. To change the password, the user can
-modify the label, for example by appending a number. Certain password
-managers also have different settings to generate tokens of different
-lengths or compositions (symbols or not, etc) to accommodate different
+label (generally the host name) into a site-specific password using some
+cryptographic functions. To change the generated password, the user can
+modify the label, for example by appending a number. Some password
+hashers also have different settings to generate tokens of different
+lengths or compositions (symbols or not, etc.) to accommodate different
 site-specific password policies.
 
 The whole concept of password hashers relies on the concept of one-way
-[cryptographic hash functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function)
-or
-[key derivation functions](https://en.wikipedia.org/wiki/Key_derivation_function)
-that take an arbitrary input string (say a password) and generate a
-unique token, from which it is impossible to guess the original input
-string. Password hashers are generally written as Javascript
-bookmarklets or browser plugins and have been around for over a
-decade.
-
-The biggest advantage of password hashers is that you only
-need to remember a single password. You do
-not need to carry around a password manager vault: there's no "state" (other
-than site-specific settings, which can be easily guessed). A password
-hasher named [Master Password](https://ssl.masterpasswordapp.com/) makes a compelling case against
-traditional password managers in their
+[cryptographic hash
+functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function) or
+[key derivation
+functions](https://en.wikipedia.org/wiki/Key_derivation_function) that
+take an arbitrary input string (say a password) and generate a unique
+token, from which it is impossible to guess the original input string.
+Password hashers are generally written as JavaScript bookmarklets or
+browser plugins and have been around for over a decade.
+
+The biggest advantage of password hashers is that you only need to
+remember a single password. You do not need to carry around a password
+manager vault: there's no "state" (other than site-specific settings,
+which can be easily guessed). A password hasher named [Master
+Password](https://ssl.masterpasswordapp.com/) makes a compelling case
+against traditional password managers in its
 [documentation](https://ssl.masterpasswordapp.com/security.html#loss):
 
-> It's as though the implicit assumptions are that everybody backs all
-> of their stuff up to at least two different devices and backups in
-> the cloud in at least two separate countries. Well, people don't
-> always have perfect backups. In fact, they usually don't have *any*.
+<div class="BigQuote">
 
-They go on to argue that, when you lose your password, "You lose
-everything. You lose your own identity."
+It's as though the implicit assumptions are that everybody backs all of
+their stuff up to at least two different devices and backups in the
+cloud in at least two separate countries. Well, **people don't always
+have perfect backups**. In fact, they usually don't have *any*.
+
+</div>
+
+It goes on to argue that, when you lose your password: "<span>You lose
+everything. You lose your own identity.</span>"
 
 The stateless nature of password hashers also means you do not need to
 use cloud services to synchronize your passwords, as there is
 (generally, more on that later) no state to carry around. This means,
 for example, that the list of accounts that you have access to is only
 stored in your head, and not in some online database that could be
-hacked without your knowledge. The downside of this is, of course,
-that attackers do not actually need to have access to your password
-manager to start cracking it: they can try to guess your master key
-without ever stealing from you anything else than a single token you
-used to login on some random website.
+hacked without your knowledge. The downside of this is, of course, that
+attackers do not actually need to have access to your password hasher to
+start cracking it: they can try to guess your master key without ever
+stealing anything from you other than a single token you used to log
+into some random web site.
 
 Password hashers also *necessarily* generate *unique* passwords for
 every site you use them on. While you can also do this with password
-managers, it is not an enforced decision. With hashers, you get
-distinct and strong passwords for every site with little effort. 
+managers, it is not an enforced decision. With hashers, you get distinct
+and strong passwords for every site with no effort.
 
-The problem with password hashers
----------------------------------
+#### The problem with password hashers
 
-If hashers are so great, why would you use a password manager?
-Programs like [LessPass](https://lesspass.com/) and Master Password
-seem to have strong crypto that is well implemented, why isn't
-everyone using those tools?
+If hashers are so great, why would you use a password manager? Programs
+like [LessPass](https://lesspass.com/) and Master Password seem to have
+strong crypto that is well implemented, so why isn't everyone using
+those tools?
 
-Password hashing, as a general concept, actually has serious issues:
+Password hashing, as a general concept, actually has serious problems:
 since the hashing outputs are constantly compromised (they are sent in
-password forms to various sites, possibly hostile), it's theoretically
-possible to derive the master password and then break all generated
+password forms to various possibly hostile sites), it's theoretically
+possible to derive the master password and then break all the generated
 tokens in one shot. The use of stronger key derivation functions (like
 [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2),
-[scrypt](https://en.wikipedia.org/wiki/scrypt) or
+[scrypt](https://en.wikipedia.org/wiki/scrypt), or
 [HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code))
 or seeds (like a profile-specific secret) makes those attacks much
-harder, especially since if the seed is long enough to make brute
-force attacks infeasible. (Unfortunately, in the case of
-[Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd/related?hl=en),
-the seed is derived from `Math.random()` calls which is
-[not considered cryptograhically secure](http://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure).)
-
-Basically, as stated by Julian Morrison in 
-[this discussion](https://news.ycombinator.com/item?id=12890997):
-
-> A password is now ciphertext, not a block of line noise. Every time
-> you transmit it, you are giving away potential clues of use to an
-> attacker. [...]
-> 
-> You only have one password for all the sites, really, underneath,
-> and it's your secret key. If it's broken, it's now a skeleton-key
-> and your digital ass is theirs.
+harder, especially if the seed is long enough to make brute-force
+attacks infeasible. (Unfortunately, in the case of [Password Hasher
+Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd),
+the seed is derived from `Math.random()` calls which is [not considered
+cryptographically
+secure](http://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure).)
+
+Basically, as stated by Julian Morrison in [this
+discussion](https://news.ycombinator.com/item?id=12890997):
+
+<div class="BigQuote">
+
+A password is now ciphertext, not a block of line noise. Every time you
+transmit it, you are giving away potential clues of use to an attacker.
+\[...\]
+You only have one password for all the sites, really, underneath, and
+it's your secret key. If it's broken, it's now a skeleton-key and your
+digital ass is theirs.
+
+</div>
 
 Newer implementations like LessPass and Master Password fix this by
 using reasonable key derivation algorithms (PBKDF2 and scrypt,
@@ -116,100 +122,95 @@ password hashing competition
 ([Argon2](https://en.wikipedia.org/wiki/Argon2)) in your password

(Diff truncated)
final review from LWN
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 360eb2f..ce5d80c 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -88,8 +88,8 @@ different shared secret.
 #### Pass: the standard password manager?
 
 I am currently using [password-store](https://www.passwordstore.org/),
-or `pass`, as a password manager. It aims to be "<span>the standard Unix
-password manager</span>". `pass` is a GnuPG-based password manager that
+or pass, as a password manager. It aims to be "<span>the standard Unix
+password manager</span>". Pass is a GnuPG-based password manager that
 features a surprising number of features given its small size:
 
 -   copy-paste support
@@ -104,11 +104,11 @@ password for your LWN account and copy it to the clipboard:
         $ pass init
         $ pass generate -c lwn 20
 
-The main issue with `pass` is that it doesn't encrypt the *name* of
-those entries: if someone were to compromise my machine, they could
-easily see which sites I have access to simply by listing the passwords
-stored in `~/.password-store`. This is a deliberate design decision by
-the upstream project, as
+The main issue with pass is that it doesn't encrypt the *name* of those
+entries: if someone were to compromise my machine, they could easily see
+which sites I have access to simply by listing the passwords stored in
+`~/.password-store`. This is a deliberate design decision by the
+upstream project, as
 [stated](https://lists.zx2c4.com/pipermail/password-store/2014-June/001001.html)
 by a mailing list participant, Allan Odgaard:
 
@@ -126,7 +126,7 @@ the entire database (including the site names) if users really need that
 feature.
 
 Furthermore, there is a [tomb
-plugin](https://github.com/roddhjav/pass-tomb) for `pass` that encrypts
+plugin](https://github.com/roddhjav/pass-tomb) for pass that encrypts
 the password store in a
 [LUKS](https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup) container
 (called a "[tomb](https://github.com/dyne/Tomb)"), although it requires
@@ -167,8 +167,8 @@ subdirectories:
          1 file changed, 2 insertions(+)
          create mode 100644 Ateam/.gpg-id
 
-The above will configure `pass` to encrypt the passwords in the `Ateam`
-directory for me@example.com and joelle@example.com. `pass` depends on
+The above will configure pass to encrypt the passwords in the `Ateam`
+directory for me@example.com and joelle@example.com. Pass depends on
 GnuPG to do the right thing when encrypting files and how those
 identities are treated is entirely delegated to GnuPG's default
 configuration. This could lead to [problems](/Articles/697417/) if
@@ -193,17 +193,17 @@ algorithm GnuPG chose, you may want to try this pipeline:
         gpg: original file name=''
         test
 
-As you can see, `pass` is primarily a command-line application, which
-may make it less accessible to regular users. The community has produced
-different graphical interfaces that are either using `pass` directly or
+As you can see, pass is primarily a command-line application, which may
+make it less accessible to regular users. The community has produced
+different graphical interfaces that are either using pass directly or
 operate on the storage with their own GnuPG integration. I personally
-use `pass` in combination with
+use pass in combination with
 [Rofi](https://davedavenport.github.io/rofi/) to get quick access to my
 passwords, but less savvy users may want to try the
 [QtPass](https://qtpass.org/) interface, which should be more
-user-friendly. QtPass doesn't actually depend on `pass` and can use
-GnuPG directly to interact with the `pass` database; it is available for
-Linux, BSD, OS X, and Windows.
+user-friendly. QtPass doesn't actually depend on pass and can use GnuPG
+directly to interact with the pass database; it is available for Linux,
+BSD, OS X, and Windows.
 
 #### Browser password managers
 
@@ -227,8 +227,8 @@ in 2013.
 In Firefox, there's an optional, profile-specific master password that
 unlocks all passwords. In this case, the issue is that browsers are
 generally always open, so the vault is always unlocked. And this is for
-users that actually *do* pick a master password; users are often are
-often completely unaware that they should set one.
+users that actually *do* pick a master password; users are often
+completely unaware that they should set one.
 
 The unlocking mechanism is a typical convenience-security trade-off:
 either users need to constantly input their master passwords to login or
@@ -263,17 +263,16 @@ Another alternative password manager, briefly mentioned in the previous
 article, is the minimalistic
 [Assword](https://finestructure.net/assword/) password manager that,
 despite its questionable name, is also interesting. Its main advantage
-over `pass` is that it uses a single encrypted JSON file for storage,
-and therefore doesn't leak the name of the entries by default. In
-addition to copy/paste, Assword also supports automatically entering
-passphrases in fields using the
-[xdo](https://www.semicomplete.com/projects/xdotool) library. Like
-`pass`, it uses GnuPG to encrypt passphrases. According to Assword
-maintainer Daniel Kahn Gillmor in email, the main issue with Assword is
-"interaction between generated passwords and insane password policies".
-He gave the example of the Time-Warner Cable registration form that
-requires, among other things, "letters and numbers, between 8 and 16
-characters and not repeat the same characters 3 times in a row".
+over pass is that it uses a single encrypted JSON file for storage, and
+therefore doesn't leak the name of the entries by default. In addition
+to copy/paste, Assword also supports automatically entering passphrases
+in fields using the [xdo](https://www.semicomplete.com/projects/xdotool)
+library. Like pass, it uses GnuPG to encrypt passphrases. According to
+Assword maintainer Daniel Kahn Gillmor in email, the main issue with
+Assword is "interaction between generated passwords and insane password
+policies". He gave the example of the Time-Warner Cable registration
+form that requires, among other things, "letters and numbers, between 8
+and 16 characters and not repeat the same characters 3 times in a row".
 
 Another well-known password manager is the commercial
 [LastPass](https://lastpass.com/) service which
@@ -301,10 +300,10 @@ access the encrypted database.
 
 When you share a password database within a team, how do you remove
 access to a member of the team? While you can, for example, re-encrypt a
-`pass` database with new keys (thereby removing or adding certain
+pass database with new keys (thereby removing or adding certain
 accesses) or change the password on a KeePass database, a hostile party
 could have made a backup of the database before the revocation. Indeed,
-in the case of `pass`, older entries are still in the Git history. So
+in the case of pass, older entries are still in the Git history. So
 access revocation is a problematic issue found with all shared password
 managers, as it may actually mean going through every password and
 changing them online.

final review from dkg
diff --git a/blog/hashers-history.mdwn b/blog/hashers-history.mdwn
index 7eb0757..2ed6264 100644
--- a/blog/hashers-history.mdwn
+++ b/blog/hashers-history.mdwn
@@ -38,11 +38,15 @@ bookmarklet that was
 originally using MD5 as well but now supports SHA512 now although
 still
 [limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
+(which needlessly limits the entropy of the resulting password)
 and still
 [defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
 with
 [not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
-(10). Note that Chris Zarate, the supergenpass author, actually
+(10, when key derivation recommendations are more generally around 10
+000, so that it's slower to bruteforce).
+
+Note that Chris Zarate, the supergenpass author, actually
 credits Nic Wolff as the inspiration for his
 implementation. Supergenpass is still in active development and is
 available for the browser (as a
@@ -52,8 +56,8 @@ available for the browser (as a
 allows you to modify the password length, but also add an extra
 profile secret which adds to the password and generates a personalized
 [identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
-prevent phishing but it also introduces an interesting protection,
-only found later in Password Hasher Plus. So the
+prevent phishing but it also introduces the interesting protection,
+the profile-specific secret only found later in Password Hasher Plus. So the
 [Supergenpass algorithm](https://github.com/chriszarate/supergenpass-lib/blob/eb9ee92050813d498229bfe0e6ccbcb87124cf90/src/lib/generate.js#L32) looks something like this:
 
     token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
@@ -87,7 +91,7 @@ So the
 [algorithm](https://addons.mozilla.org/en-US/firefox/files/browse/140427/file/chrome/content/passhash-common.js#L298)
 here is obviously:
 
-    token = base64(HMAC(SHA1, password, domain + ":" + counter)))
+    token = base64(HMAC(SHA1, password, domain + ":" + counter)))[:8]
 
 ... although in the case of Password Hasher, there is a special
 routine that takes the token and inserts random characters in locations
@@ -144,14 +148,18 @@ glance, the LessPass source code seems
 [clear and easy to read](https://github.com/lesspass/core/blob/master/src/v2.js)
 which is always a good sign, but of course, the devil
 is in the details. One key feature that is missing from Password Hasher
-Plus is the profile-specific seed, although it should
-be more difficult, if not impossible, for a webpage script
-to steal keystrokes from a browser extension.
+Plus is the profile-specific seed, although it *should*
+be impossible, for a hostile web page 
+to steal keystrokes from a browser extension, as far as I know.
 
 The [algorithm][] then gets a little more interesting:
 
     entropy = PBKDF2(SHA256, masterPassword, domain + username + counter, rounds, length)
-    where rounds = 10000 and length = 32
+    where
+        rounds=10000
+        length=32
+        
+`entropy` is then used to pick characters to match the chosen profile.
 
 [algorithm]: https://github.com/lesspass/core/blob/24c339e/src/v2.js#L15
 
@@ -197,7 +205,7 @@ of its algorithm (although Hashpass.com does give out OpenSSL
 commandline examples...), which led to its reuse in another
 application called
 [freepass](https://github.com/myfreeweb/freepass). The Master Password
-app *also* doubles as a traditionnal password manager...
+app *also* doubles as a stateful password manager...
 
 Internal notes
 --------------
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 269e5de..7bc60aa 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -24,21 +24,23 @@ What is a password hasher?
 --------------------------
 
 A password hasher is a piece of software that turns a single master
-password into multiple passwords by hashing the master password and a
-unique identifier (generally the hostname) to create a site-specific
-password. To change the password, the user can modify the unique
-identifier, for example by appending a number. Certain password managers
-also have different settings to generate tokens of different
+password into multiple passwords by turning the master password and a
+label (generally the hostname) into a site-specific password using
+some cryptographic functions. To change the password, the user can
+modify the label, for example by appending a number. Certain password
+managers also have different settings to generate tokens of different
 lengths or compositions (symbols or not, etc) to accommodate different
 site-specific password policies.
 
-The whole concept of password hashers relies on the concept of
-one-way
+The whole concept of password hashers relies on the concept of one-way
 [cryptographic hash functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function)
-that take an input and generate an a unique fixed size string, from
-which it is impossible to guess the original input. Password hashers
-are generally written as Javascript bookmarklets or browser plugins
-and have been around for over a decade.
+or
+[key derivation functions](https://en.wikipedia.org/wiki/Key_derivation_function)
+that take an arbitrary input string (say a password) and generate a
+unique token, from which it is impossible to guess the original input
+string. Password hashers are generally written as Javascript
+bookmarklets or browser plugins and have been around for over a
+decade.
 
 The biggest advantage of password hashers is that you only
 need to remember a single password. You do
@@ -117,7 +119,9 @@ re-encrypt your database. With a password hasher, it's not so easy:
 changing the algorithm means logging in to *every* site you visited
 and changing the password. As someone who used a password hasher for a
 few years, I can tell you this is really impractical: you quickly end
-up with *hundreds* of passwords...
+up with *hundreds* of passwords... The LessPass people tried to
+facilitate this, but they ended up mostly
+[giving up](https://github.com/lesspass/lesspass/issues/36).
 
 Which brings us to the question of state. A lot of those tools claim
 to work "without a server" or being "stateless" and while those claims
@@ -159,8 +163,8 @@ especially severe for password hashers.
 Furthermore, I have had difficulty using password managers in unified
 login environments like Wikipedia's or StackExchange's single sign-on
 systems: because they allow you to login with the same password on
-multiple sites, you need to choose (and remember!) what identifier you
-used when signing in. Did I sign in on Stackoverflow.com? Or was it
+multiple sites, you need to choose (and remember!) what label you used
+when signing in. Did I sign in on Stackoverflow.com? Or was it
 Stackexchange.com?
 
 Also, as mentioned in the
@@ -206,3 +210,6 @@ recommendation shorter anyways: "remember a few
 [carefully generated passwords](https://lwn.net/Articles/713806/) and
 shove everything else in a
 [password manager](https://lwn.net/Articles/714473/)".
+
+Many thanks to Daniel Kahn Gillmor for the thorough reviews provided
+for the passwords series.

authors agrees to quote
diff --git a/blog/hashers-history.mdwn b/blog/hashers-history.mdwn
index b6edeb0..7eb0757 100644
--- a/blog/hashers-history.mdwn
+++ b/blog/hashers-history.mdwn
@@ -303,6 +303,11 @@ author's response:
 10:35 <anarcat> lhunath: thanks for the response, i'll see what i can keep in the article... 
 10:35 <anarcat> lhunath: there may be a separate article about password hashers history where i go into specific details of the algorithms where this will be very relevant
 10:35 <anarcat> can i quote from this conversation?
+10:45 <lhunath> anarcat: certainly.
+10:46 <anarcat> lhunath: thanks!
+10:46 <anarcat> lhunath: good bye
+10:46 -!- anarcat [~anarcat@unaffiliated/anarcat] has left #masterpassword []
+--- Log closed dim fév 19 10:46:31 2017
 
 
 

make a title
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 594699f..269e5de 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -1,3 +1,6 @@
+The case against password hashers
+=================================
+
 In previous articles, we have covered
 [how to generate passwords](https://lwn.net/Articles/713806/) and a
 [review of various password managers](https://lwn.net/Articles/714473/). There
@@ -69,7 +72,7 @@ every site you use them on. While you can also do this with password
 managers, it is not an enforced decision. With hashers, you get
 distinct and strong passwords for every site with little effort. 
 
-The case against password hashers
+The problem with password hashers
 ---------------------------------
 
 If hashers are so great, why would you use a password manager?

notes in the hasher history
diff --git a/blog/hashers-history.mdwn b/blog/hashers-history.mdwn
index 0b05a85..b6edeb0 100644
--- a/blog/hashers-history.mdwn
+++ b/blog/hashers-history.mdwn
@@ -50,7 +50,7 @@ available for the browser (as a
 (as an
 [webpage](https://chriszarate.github.io/supergenpass/mobile/)). Supergenpass
 allows you to modify the password length, but also add an extra
-profile password which adds to the secret and generates a personalized
+profile secret which adds to the password and generates a personalized
 [identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
 prevent phishing but it also introduces an interesting protection,
 only found later in Password Hasher Plus. So the
@@ -58,18 +58,18 @@ only found later in Password Hasher Plus. So the
 
     token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
 
-Anothor popular implementation is the Wiijo password hasher,
+Another popular implementation is the Wijjo Password Hasher,
 [created around 2006](http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/).
 It was probably the first shipped as a
 [browser extension](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
 which greatly improved the security of the product as users didn't
-have to continually download the software on the fly. Wiijo's
+have to continually download the software on the fly. Wijjo's
 algorithm also improved on the above algorithms, as it uses HMAC-SHA1
 instead of plain SHA-1 or HMAC-MD5, which makes it harder to recover
-the plaintext. Password hasher allows you to set different password
+the plaintext. Password Hasher allows you to set different password
 policies (use digits, punctuation, mixed case, special characters and
 password length) and saves the site names it uses for future
-reference. It also happens that the Wiijo password hasher, in turn,
+reference. It also happens that the Wijjo Password Hasher, in turn,
 took its inspiration on *different* project,
 [hashapass.com](http://www.hashapass.com/),
 [created in 2006](http://web.archive.org/web/20060702050519/http://www.hashapass.com/)
@@ -93,22 +93,22 @@ here is obviously:
 routine that takes the token and inserts random characters in locations
 determined by the sum of the values of the characters in the token.
 
-Years later, in 2010, Eric Woodruff ported the Wiijo "password hasher"
+Years later, in 2010, Eric Woodruff ported the Wijjo Password Hasher
 to Chrome and called it
 [Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd?hl=en).
-Like the original password hasher, the "plus" version also keeps those
+Like the original Password Hasher, the "plus" version also keeps those
 settings in the extension and uses HMAC-SHA-1 to generate the
-password, as it is designed to be backwards-compatible with the Wiijo
-password hasher. Woodruff did add an one interesting feature: a
+password, as it is designed to be backwards-compatible with the Wijjo
+Password Hasher. Woodruff did add one interesting feature: a
 profile-specific secret key that gets mixed in to create the security
-token. Stealing the master password is therefore not enough to
+token, like what SuperGenPass does now. Stealing the master password is therefore not enough to
 generate tokens anymore. This solves one security concern with
 Password Hasher: an hostile page could watch your keystrokes and steal
 your master password and use it to derive passwords on other
 sites. Having a profile-specific secret key, not accessible to the
-site's Javascript works around that issue, but one could argue that
-typing the master password directly in the password file, while
-convenient, is probably just a bad idea in retrospect. The final
+site's Javascript works around that issue, but 
+typing the master password directly in the password field, while
+convenient, is just a bad idea, period. The final
 algorithm looks something like:
 
     token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
@@ -119,13 +119,15 @@ nowadays. I would have expected the simplest version:
 
     token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain))
 
+(maybe this is for the extension attack?)
+
 Password Hasher Plus then takes the token and applies the same
 special character insertion routine as the Password Hasher.
 
 Last year, [Guillaume Vincent](http://guillaumevincent.com/) a french
 self-described "humanist and scuba diving fan" released the
 [lesspass](https://lesspass.com/) extension for Chrome, Firefox and
-Android. Lesspass introduces numerous interesting functionalities. It
+Android. Lesspass introduces several interesting features. It
 is probably the first to include a
 [commandline version](https://github.com/lesspass/cli). It also
 [uses](https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4) a
@@ -133,17 +135,17 @@ more robust key derivation algorithm
 ([PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)) and takes into
 account the username on the site, allowing multi account support. The
 original release (version 1) used only 8192 rounds which is now
-considered too low. In the
+[considered too low](http://stackoverflow.com/questions/6054082/recommended-of-iterations-when-using-pbkdf2-sha256). In the
 [bug report](https://github.com/lesspass/lesspass/issues/38) it was
 interesting to note that LessPass couldn't do the usual practice of
 running the key derivation for 1 second to determine the number of
 rounds needed as the results need to be deterministic. At first
 glance, the LessPass source code seems
 [clear and easy to read](https://github.com/lesspass/core/blob/master/src/v2.js)
-at first glance which is always a good sign, but of course, the devil
-is in the details. One key feature it is missing from Password Hasher
-Plus is the profile-specific seed, although one could argue it should
-be more difficult, if not impossible, for a webpage Javascript script
+which is always a good sign, but of course, the devil
+is in the details. One key feature that is missing from Password Hasher
+Plus is the profile-specific seed, although it should
+be more difficult, if not impossible, for a webpage script
 to steal keystrokes from a browser extension.
 
 The [algorithm][] then gets a little more interesting:
@@ -153,7 +155,7 @@ The [algorithm][] then gets a little more interesting:
 
 [algorithm]: https://github.com/lesspass/core/blob/24c339e/src/v2.js#L15
 
-(Confused by the pbkdg2 implementation here:
+(Confused by the PBKDF2 implementation here:
 https://github.com/lesspass/core/blob/master/src/pbkdf2.js - ImportKey
 doesn't support PBKDF2?? it's just something to extract key material?
 and then later, why AES-CTR??)
@@ -164,13 +166,11 @@ There is also a
 algorithm).
 
 A review of password hashers would hardly be complete without
-mentioning the [Master Password](http://masterpasswordapp.com/),
-probably the
-[definite algorithm](http://masterpasswordapp.com/algorithm.html) for
-password hashers. While the applications surrounding the project are
+mentioning the [Master Password](http://masterpasswordapp.com/) and its
+[elaborate algorithm](http://masterpasswordapp.com/algorithm.html). While the applications surrounding the project are
 not as refined (there is no web browser plugin and the
 [web interface](https://js.masterpasswordapp.com/) can't be easily
-turned into a bookmarklet), the algorithm has been well developed. In all the
+turned into a bookmarklet), the algorithm has been well developed. Of all the
 password managers reviewed here, Master Password uses one of the
 strongest key derivation algorithms out there,
 [scrypt](https://en.wikipedia.org/wiki/Scrypt):
@@ -187,15 +187,124 @@ strongest key derivation algorithms out there,
 Master Password the uses one of 6 sets of "templates" specially
 crafted to be "easy for a user to read from a screen and type using a
 keyboard or smartphone" and "compatible with most site's password
-policies". For example, the default template mixes vowels,
+policies", our "transferable" criteria defined in [the first passwords article](https://lwn.net/Articles/713806/). For example, the default template mixes vowels,
 consonants, numbers and symbols, but carefully avoiding possibly
 visibly similar characters like `O` and `0` or `i` and `1` (although
 it does mix `1` and `l`, oddly enough).
 
 The main strength of Master Password seems to be the clear definition
-of its algorithm, which led to its reuse in another application called
-[freepass](https://github.com/myfreeweb/freepass). 
+of its algorithm (although Hashpass.com does give out OpenSSL
+commandline examples...), which led to its reuse in another
+application called
+[freepass](https://github.com/myfreeweb/freepass). The Master Password
+app *also* doubles as a traditionnal password manager...
+
+Internal notes
+--------------
+
+not for publication.
+
+define why strong key derivation is important, to quote dkg:
+
+> if we're going to argue for "strong key derivation algorithms", then we
+> need to explain what "strength" means here.  i think "strength" in this
+> context means "requires significant investment of RAM and/or CPU cycles
+> to compute".  Why is this important?  It's important because it
+> increases the cost to an attacker who knows one of your tokens and the
+> domain that goes with it, and who decides to walk the space of possible
+> master passwords to see what they can find that would match.
+
+maybe mention this:
+
+http://scilogs.spektrum.de/hlf/mental-cryptography-and-good-passwords/
+https://programmingpraxis.com/2014/09/26/blums-mental-hash/
+
+requires remembering a password that is basically a string of 26
+digits, plus compute modulo arithmetics on the output.
+
+considered https://github.com/palant/easypasswords, which uses
+PBKDF2-HMAC-SHA1. has a nice review:
+https://palant.de/2016/04/20/security-considerations-for-password-generators
+i am not sure it is notable enough over lesspass to warrant
+coverage. lesspass does seem a bit more usable, and covering it allows
+us to mention more issues.
+
+master password was criticized here: 
+
+https://palant.de/2016/04/20/security-considerations-for-password-generators#fn8802245455717d2bceea74
+
+author's response:
+
+--- Log opened sam fév 18 12:56:25 2017
+12:56 -!- anarcat [~anarcat@unaffiliated/anarcat] has joined #masterpassword
+12:56 -!- Irssi: Join to #masterpassword was synced in 1 secs
+12:56 <anarcat> hi
+12:56 <anarcat> why isn't http://masterpasswordapp.com accessible over https?
+12:57 <anarcat> i mean i see https://ssl.masterpasswordapp.com/ - but that's rather clunky, isn't it?
+16:46 -!- alberto [~alberto@host247-22-dynamic.58-82-r.retail.telecomitalia.it] has joined #masterpassword
+16:46 -!- alberto is now known as Guest10015
+16:50 -!- Guest10015 [~alberto@host247-22-dynamic.58-82-r.retail.telecomitalia.it] has quit [Client Quit]
+18:08 <lhunath> anarcat: yeah, it's an IP issue.
+18:08 <lhunath> http://masterpasswordapp.com is served from AWS, which doesn't support true HTTPS.
+18:08 <anarcat> wth

(Diff truncated)
final review before LWN churn
ditch easypass because it doesn't differ much from lastpass
ditch mental hashes because wtf.. too complicated? portier, lastpass,
1password, should have been covered in previous articles...
tired of re-reading the same HN thread too...
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index aa5cbea..594699f 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -1,10 +1,11 @@
-In previous articles, we have covered [how to generate passwords](https://lwn.net/Articles/713806/) and a
-[review of various password managers](https://lwn.net/Articles/714473/). There is, however, a third way of managing
-passwords other than remembering them or encrypting them in a "vault",
-and that is what I call "password hashing". You may know those as
-"deterministic or stateless password managers" but I find the
-"password manager" denomination to be confusing because it doesn't
-actually store any password.
+In previous articles, we have covered
+[how to generate passwords](https://lwn.net/Articles/713806/) and a
+[review of various password managers](https://lwn.net/Articles/714473/). There
+is, however, a third way of managing passwords other than remembering
+them or encrypting them in a "vault", and that is what I call
+"password hashing". You may know those as "deterministic or stateless
+password managers" but I find the "password manager" denomination to
+be confusing because it doesn't actually store any password.
 
 I do not think password hashers represent a good security tradeoff so
 I generally do not recommend their use, unless you really do not have
@@ -54,14 +55,14 @@ everything. You lose your own identity."
 
 The stateless nature of password hashers also means you do not need to
 use cloud services to synchronize your passwords, as there is
-(generally, more on that later) no state to carry around. This means
-that the list of accounts, for example, that you have access to is
-only stored in your head, and not in some online database that could
-be hacked without your knowledge. The downside of this is, of course,
+(generally, more on that later) no state to carry around. This means,
+for example, that the list of accounts that you have access to is only
+stored in your head, and not in some online database that could be
+hacked without your knowledge. The downside of this is, of course,
 that attackers do not actually need to have access to your password
 manager to start cracking it: they can try to guess your master key
-(assuming they have even only one of your passwords) without ever
-stealing anything else from you.
+without ever stealing from you anything else than a single token you
+used to login on some random website.
 
 Password hashers also *necessarily* generate *unique* passwords for
 every site you use them on. While you can also do this with password
@@ -77,19 +78,19 @@ seem to have strong crypto that is well implemented, why isn't
 everyone using those tools?
 
 Password hashing, as a general concept, actually has serious issues:
-since the hashing outputs are constantly compromised (they are sent to
-various third party, possibly hostile sites in password forms), it's theoretically possible to derive
-the master password and then break all generated tokens in one shot. The use
-of stronger key derivation functions (like
+since the hashing outputs are constantly compromised (they are sent in
+password forms to various sites, possibly hostile), it's theoretically
+possible to derive the master password and then break all generated
+tokens in one shot. The use of stronger key derivation functions (like
 [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2),
 [scrypt](https://en.wikipedia.org/wiki/scrypt) or
-[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)) or
-seeds (like a profile-specific secret) makes those attacks much
+[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code))
+or seeds (like a profile-specific secret) makes those attacks much
 harder, especially since if the seed is long enough to make brute
-force attacks infeasible. Unfortunately, in the case of
+force attacks infeasible. (Unfortunately, in the case of
 [Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd/related?hl=en),
 the seed is derived from `Math.random()` calls which is
-[not considered cryptograhically secure](http://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure).
+[not considered cryptograhically secure](http://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure).)
 
 Basically, as stated by Julian Morrison in 
 [this discussion](https://news.ycombinator.com/item?id=12890997):
@@ -108,47 +109,58 @@ respectively), but who knows how long those will hold? To give a
 concrete example, if you would like to use the new winner of the
 password hashing competition
 ([Argon2](https://en.wikipedia.org/wiki/Argon2)) in your password
-manager, you can easily re-encrypt your database. With a password
-hasher, it's not so easy: changing the algorithm means logging in to
-*every* site you visited and changing the password. As someone who
-used a password hasher for a few years, I can tell you this is really
-impractical: you quickly end up with *hundreds* of passwords...
+manager, you can patch the program (or wait for an update) and
+re-encrypt your database. With a password hasher, it's not so easy:
+changing the algorithm means logging in to *every* site you visited
+and changing the password. As someone who used a password hasher for a
+few years, I can tell you this is really impractical: you quickly end
+up with *hundreds* of passwords...
 
 Which brings us to the question of state. A lot of those tools claim
 to work "without a server" or being "stateless" and while those claims
 are partly true, hashers are way more usable (and more secure, with
-profile secrets) when they *do* keep some
-sort of state. For example, Password Hasher Plus records in your
-browser profile which site you visited and which settings were used on
-each site which makes it easier to comply with weird password
-policies. But then that state needs to be backed up and synchronized across
-multiple devices, which led LessPass to offer a service
-(which you can also self-host) to keep those settings online. At this
-point, a key benefit of the password hasher approach (not keeping
-state) just disappears and you might as well use a password manager.
+profile secrets) when they *do* keep some sort of state. For example,
+Password Hasher Plus records, in your browser profile, which site you
+visited and which settings were used on each site which makes it
+easier to comply with weird password policies. But then that state
+needs to be backed up and synchronized across multiple devices, which
+led LessPass to offer a service (which you can also self-host) to keep
+those settings online. At this point, a key benefit of the password
+hasher approach (not keeping state) just disappears and you might as
+well use a password manager.
 
 The other issue with password hashers is choosing the right one from
 the start, because changing software generally means changing the
 algorithm, and therefore changing passwords everywhere. All of them
-have severe security vs usability trade-offs. For example, LessPass has what seems
-to be a sound cryptographic implementation, but using it requires
-you to click on the icon, fill in the fields, click generate then copy
-the password in the field, which means at least 4-5 actions per password. The
-venerable
+have severe security vs usability trade-offs. For example, LessPass
+has what seems to be a sound cryptographic implementation, but using
+it requires you to click on the icon, fill in the fields, click
+generate then copy the password in the field, which means at least 4-5
+actions per password. The venerable
 [Password Hasher](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
-is way easier to use, but exposes the master password to possibly
-hostile sites, which could simply use Javascript to sniff the password
-while it is typed. While there are workarounds implemented in
-Password Hasher Plus (the profile-specific secret), both tools are more or less abandoned now. The
-[Password Hasher homepage](http://wijjo.com/passhash/), linked from
-the extension page, is now a 404. Password Hasher Plus hasn't seen a
-release in over a year and there is no space for collaborating on the
-software - the homepage is simply the author's Google+ page with no
-information on the project. I couldn't actually find the source online
-and had to download the Chrome extension by hand to review the source
-code.
-
-As mentioned in the
+is way easier to use, but makes you type the master password directly
+in the site's password form, so hostile sites can simply use
+Javascript to sniff the master password while it is typed. While there
+are workarounds implemented in Password Hasher Plus (the
+profile-specific secret), both tools are more or less abandoned
+now. The [Password Hasher homepage](http://wijjo.com/passhash/),
+linked from the extension page, is now a 404. Password Hasher Plus
+hasn't seen a release in over a year and there is no space for
+collaborating on the software - the homepage is simply the author's
+Google+ page with no information on the project. I couldn't actually
+find the source online and had to download the Chrome extension by
+hand to review the source code. Software abandonment is a serious
+issue for every project out there, but I would argue that it is
+especially severe for password hashers.
+
+Furthermore, I have had difficulty using password managers in unified
+login environments like Wikipedia's or StackExchange's single sign-on
+systems: because they allow you to login with the same password on
+multiple sites, you need to choose (and remember!) what identifier you
+used when signing in. Did I sign in on Stackoverflow.com? Or was it
+Stackexchange.com?
+
+Also, as mentioned in the
 [previous article](https://lwn.net/Articles/714473/) about password
 managers, web-based password managers have serious security
 flaws. Since more than a few password hashers are implemented using
@@ -160,15 +172,24 @@ disclosures.
 Finally, some of the password hashers use dubious crypto primitives
 that we valid and interesting a decade ago, but are really showing
 their age now. Stanford's
-[pwdhash](https://crypto.stanford.edu/PwdHash) uses MD5 (through HMAC,
-but still), [considered](https://www.kb.cert.org/vuls/id/836068)
-"cryptographically broken and unsuitable for further use". Password
-Hasher and Password Hasher Plus use a *homegrown* `hmac_sha1` function
-to derive a password from the master password, the site tag and a
-profile-specific secret. While the HMAC secret adds a good layer of
-security, [SHA-1](https://en.wikipedia.org/wiki/SHA-1) is not
-considered a sufficient key derivation function anymore, especially
-not with a single round.
+[pwdhash](https://crypto.stanford.edu/PwdHash) uses MD5,
+[considered](https://www.kb.cert.org/vuls/id/836068)
+"cryptographically broken and unsuitable for further use". We have
+seen
+[partial key recovery attacks against MD5 already](https://tools.ietf.org/html/rfc6151#ref-COYI2006)
+and while those do not allow an attacker to recover the full master
+password yet (especially not with HMAC-MD5), I would not recommend
+anyone use MD5 in anything at this point, especially if changing that
+algorithm later is so hard. Password Hasher and Password Hasher Plus
+use a Javascript `hmac_sha1` function picked off
+[some site on the internet](http://pajhome.org.uk/crypt/md5/) to
+derive tokens. While the HMAC secret adds a good layer of security,
+using a *single* round of [SHA-1](https://en.wikipedia.org/wiki/SHA-1)
+to derive a token from a password is generally considered weak: WPA2
+(standardized in 2004) uses 4096 iterations of HMAC-SHA1. A recent
+National Institute of Standards and Technology (NIST) report also
+[recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-verifiers)
+"at least 10,000 iterations of the hash function".
 
 Conclusion
 ----------
@@ -182,38 +203,3 @@ recommendation shorter anyways: "remember a few
 [carefully generated passwords](https://lwn.net/Articles/713806/) and
 shove everything else in a

(Diff truncated)
review from dkg
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 198dd28..aa5cbea 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -6,10 +6,15 @@ and that is what I call "password hashing". You may know those as
 "password manager" denomination to be confusing because it doesn't
 actually store any password.
 
+I do not think password hashers represent a good security tradeoff so
+I generally do not recommend their use, unless you really do not have
+access to reliable storage you can access readily.
+
 In this text, I use the word "password" for a random string used to
 unlock things, but "token" to represent a generated random string that
-the user doesn't need to remember. The input of a password hasher is
-a password and the output of a password hasher is a token.
+the user doesn't need to remember. The input of a password hasher is a
+password with some site-specific context and the output of a password
+hasher is a token.
 
 What is a password hasher?
 --------------------------
@@ -19,12 +24,12 @@ password into multiple passwords by hashing the master password and a
 unique identifier (generally the hostname) to create a site-specific
 password. To change the password, the user can modify the unique
 identifier, for example by appending a number. Certain password managers
-also have different settings to generate passwords of different
+also have different settings to generate tokens of different
 lengths or compositions (symbols or not, etc) to accommodate different
 site-specific password policies.
 
 The whole concept of password hashers relies on the concept of
-one-way,
+one-way
 [cryptographic hash functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function)
 that take an input and generate an a unique fixed size string, from
 which it is impossible to guess the original input. Password hashers
@@ -32,7 +37,7 @@ are generally written as Javascript bookmarklets or browser plugins
 and have been around for over a decade.
 
 The biggest advantage of password hashers is that you only
-need to remember a password. You do
+need to remember a single password. You do
 not need to carry around a password manager vault: there's no "state" (other
 than site-specific settings, which can be easily guessed). A password
 hasher named [Master Password](https://ssl.masterpasswordapp.com/) makes a compelling case against
@@ -72,19 +77,21 @@ seem to have strong crypto that is well implemented, why isn't
 everyone using those tools?
 
 Password hashing, as a general concept, actually has serious issues:
-if a single token is compromised, it's theoretically possible to derive
-the master password and then break all passwords in one shot. The use
+since the hashing outputs are constantly compromised (they are sent to
+various third party, possibly hostile sites in password forms), it's theoretically possible to derive
+the master password and then break all generated tokens in one shot. The use
 of stronger key derivation functions (like
 [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2),
 [scrypt](https://en.wikipedia.org/wiki/scrypt) or
 [HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)) or
 seeds (like a profile-specific secret) makes those attacks much
-harder, especially since that key secret is long enough to make brute
+harder, especially since if the seed is long enough to make brute
 force attacks infeasible. Unfortunately, in the case of
 [Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd/related?hl=en),
-that secret key is derived from `Math.random()` calls which is
-[not considered cryptograhically secure](http://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure). As
-stated in
+the seed is derived from `Math.random()` calls which is
+[not considered cryptograhically secure](http://stackoverflow.com/questions/5651789/is-math-random-cryptographically-secure).
+
+Basically, as stated by Julian Morrison in 
 [this discussion](https://news.ycombinator.com/item?id=12890997):
 
 > A password is now ciphertext, not a block of line noise. Every time
@@ -97,34 +104,42 @@ stated in
 
 Newer implementations like LessPass and Master Password fix this by
 using reasonable key derivation algorithms (PBKDF2 and scrypt,
-respectively), but who knows how long those will hold?  With a
-password manager, if new attacks are found, you can easily re-encrypt
-your database. With a password hasher, it's not so easy: changing the
-algorithm means logging in to *every* site you visited and changing
-the password. As someone who used a password hasher for a few years, I
-can tell you this is really impractical: you quickly end up with
-*hundreds* of passwords...
+respectively), but who knows how long those will hold? To give a
+concrete example, if you would like to use the new winner of the
+password hashing competition
+([Argon2](https://en.wikipedia.org/wiki/Argon2)) in your password
+manager, you can easily re-encrypt your database. With a password
+hasher, it's not so easy: changing the algorithm means logging in to
+*every* site you visited and changing the password. As someone who
+used a password hasher for a few years, I can tell you this is really
+impractical: you quickly end up with *hundreds* of passwords...
 
 Which brings us to the question of state. A lot of those tools claim
 to work "without a server" or being "stateless" and while those claims
-are partly true, hashers are way more usable when they *do* keep some
+are partly true, hashers are way more usable (and more secure, with
+profile secrets) when they *do* keep some
 sort of state. For example, Password Hasher Plus records in your
 browser profile which site you visited and which settings were used on
-each site. LessPass even pushed this further by offering a service
-(possibly self-hosted) to host such settings for you online.
+each site which makes it easier to comply with weird password
+policies. But then that state needs to be backed up and synchronized across
+multiple devices, which led LessPass to offer a service
+(which you can also self-host) to keep those settings online. At this
+point, a key benefit of the password hasher approach (not keeping
+state) just disappears and you might as well use a password manager.
 
 The other issue with password hashers is choosing the right one from
 the start, because changing software generally means changing the
 algorithm, and therefore changing passwords everywhere. All of them
-have significant usability trade-offs. For example, LessPass requires
+have severe security vs usability trade-offs. For example, LessPass has what seems
+to be a sound cryptographic implementation, but using it requires
 you to click on the icon, fill in the fields, click generate then copy
-the password in the field. At least 4-5 actions per password. The
+the password in the field, which means at least 4-5 actions per password. The
 venerable
 [Password Hasher](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
 is way easier to use, but exposes the master password to possibly
 hostile sites, which could simply use Javascript to sniff the password
-while it is typed. While there are workarounds (the profile secret) in
-Password Hasher Plus, both tools are more or less abandoned now. The
+while it is typed. While there are workarounds implemented in
+Password Hasher Plus (the profile-specific secret), both tools are more or less abandoned now. The
 [Password Hasher homepage](http://wijjo.com/passhash/), linked from
 the extension page, is now a 404. Password Hasher Plus hasn't seen a
 release in over a year and there is no space for collaborating on the
@@ -144,10 +159,9 @@ disclosures.
 
 Finally, some of the password hashers use dubious crypto primitives
 that we valid and interesting a decade ago, but are really showing
-their age now. Standford's
-[pwdhash](https://crypto.stanford.edu/PwdHash) *still* uses MD5
-(through HMAC, but still),
-[considered](https://www.kb.cert.org/vuls/id/836068)
+their age now. Stanford's
+[pwdhash](https://crypto.stanford.edu/PwdHash) uses MD5 (through HMAC,
+but still), [considered](https://www.kb.cert.org/vuls/id/836068)
 "cryptographically broken and unsuitable for further use". Password
 Hasher and Password Hasher Plus use a *homegrown* `hmac_sha1` function
 to derive a password from the master password, the site tag and a
@@ -159,13 +173,12 @@ not with a single round.
 Conclusion
 ----------
 
-Password hashers look like they all have serious issues either in
-usability or in their crypto primitives. Forced to suggest one, I
-would probably point to LessPass or Master Password, depending on the
-platform of the person asking. But for now, I have resolve to avoid
-recommending password hashers and I have started the daunting process
-of switching everything to a password manager. It makes my password
-management recommendation shorter anyways: "remember a few
+Forced to suggest a password hasher, I would probably point to
+LessPass or Master Password, depending on the platform of the person
+asking. But for now, I have determined that the security drawbacks of
+password hashers are not acceptable and I do not recommend people use
+password hashers in general. It makes my password management
+recommendation shorter anyways: "remember a few
 [carefully generated passwords](https://lwn.net/Articles/713806/) and
 shove everything else in a
 [password manager](https://lwn.net/Articles/714473/)".
@@ -173,9 +186,13 @@ shove everything else in a
 internal notes
 --------------
 
+consider https://github.com/palant/easypasswords instead of master password?
+
 link to the NIST report for hash rounds?
 https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/
 
+think of unified logins!
+
 mental hash:
 
 http://scilogs.spektrum.de/hlf/mental-cryptography-and-good-passwords/
@@ -189,12 +206,6 @@ portier?
 re lastpass, 1password - proprietary server side, 2fa failure,
 mac-only... 
 
-need to review litterature about HMAC:
-
-https://benlog.com/2008/06/19/dont-hash-secrets/
-
-remember this? https://anarc.at/blog/2010-01-29-do-hash-secrets-also-use-hmac/
-
 still need to do a last review of the HN! discussion:
 
 https://news.ycombinator.com/item?id=12889807

try again
diff --git a/blog/2017-02-18-passwords-entropy.mdwn b/blog/2017-02-18-passwords-entropy.mdwn
index 18c82d7..a329696 100644
--- a/blog/2017-02-18-passwords-entropy.mdwn
+++ b/blog/2017-02-18-passwords-entropy.mdwn
@@ -2,7 +2,7 @@
 [[!meta date="2017-02-08T12:00:00-0500"]]
 [[!meta updated="2017-02-18T13:37:00-0500"]]
 
-[[!toc]]
+[[!toc startlevel=2]]
 
 Passwords are used everywhere in our modern life. Between your email
 account and your bank card, a lot of critical security infrastructure
@@ -29,7 +29,7 @@ I use the word "password" instead of "PIN" or "passphrase", which all
 roughly mean the same thing: a small piece of text that users provide to
 prove their identity.
 
-#### What makes a good password?
+## What makes a good password?
 
 A "good password" may mean different things to different people. I will
 assert that a good password has the following properties:
@@ -107,7 +107,7 @@ Everything else should be in a password manager. Those tools are
 generally under your control and should allow large enough passwords
 that the compact property is not particularly important.
 
-#### Generating secure passwords
+## Generating secure passwords
 
 We'll look now at how to generate a strong, transferable, and memorable
 password. These are most likely the passwords you will deal with most of
@@ -243,7 +243,7 @@ words, doubling the word-list length only adds a single bit of entropy.
 It is actually much better to add a word to your password than words to
 the word list that generates it.
 
-#### Generating security tokens
+## Generating security tokens
 
 As mentioned before, most password managers feature a way to generate
 strong security tokens, with different policies (symbols or not, length,
@@ -307,7 +307,7 @@ routines to generate tokens, but the procedure is the same: read from
 the kernel's entropy source (and user-generated sources in case of
 KeePass) and transform that data into a transferable string.
 
-#### Conclusion
+## Conclusion
 
 While there are many aspects to password management, we have focused on
 different techniques for users and developers to generate secure but

fix toc
diff --git a/blog/2017-02-18-passwords-entropy.mdwn b/blog/2017-02-18-passwords-entropy.mdwn
index 7cf40ba..18c82d7 100644
--- a/blog/2017-02-18-passwords-entropy.mdwn
+++ b/blog/2017-02-18-passwords-entropy.mdwn
@@ -2,7 +2,7 @@
 [[!meta date="2017-02-08T12:00:00-0500"]]
 [[!meta updated="2017-02-18T13:37:00-0500"]]
 
-[[!toc levels=2]]
+[[!toc]]
 
 Passwords are used everywhere in our modern life. Between your email
 account and your bank card, a lot of critical security infrastructure

creating tag page tag/passwords
diff --git a/tag/passwords.mdwn b/tag/passwords.mdwn
new file mode 100644
index 0000000..534ea0b
--- /dev/null
+++ b/tag/passwords.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged passwords"]]
+
+[[!inline pages="tagged(passwords)" actions="no" archive="yes"
+feedshow=10]]

put passwords article online
diff --git a/blog/2017-02-18-passwords-entropy.mdwn b/blog/2017-02-18-passwords-entropy.mdwn
new file mode 100644
index 0000000..7cf40ba
--- /dev/null
+++ b/blog/2017-02-18-passwords-entropy.mdwn
@@ -0,0 +1,328 @@
+[[!meta title="Reliably generating good passwords"]]
+[[!meta date="2017-02-08T12:00:00-0500"]]
+[[!meta updated="2017-02-18T13:37:00-0500"]]
+
+[[!toc levels=2]]
+
+Passwords are used everywhere in our modern life. Between your email
+account and your bank card, a lot of critical security infrastructure
+relies on "something you know", a password. Yet there is little standard
+documentation on how to generate good passwords. There are some
+interesting possibilities for doing so; this article will look at what
+makes a good password and some tools that can be used to generate them.
+
+There is growing concern that our dependence on passwords poses a
+fundamental security flaw. For example, passwords rely on humans, who
+can be coerced to reveal secret information. Furthermore, passwords are
+"replayable": if your password is revealed or stolen, anyone can
+impersonate you to get access to your most critical assets. Therefore,
+major organizations are trying to move away from single password
+authentication. Google, for example, is [enforcing two factor
+authentication for its employees](https://cloud.google.com/security/)
+and is considering abandoning [passwords on phones as
+well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
+although we have yet to see that controversial change implemented.
+
+Yet passwords are still here and are likely to stick around for a long
+time until we figure out a better alternative. Note that in this article
+I use the word "password" instead of "PIN" or "passphrase", which all
+roughly mean the same thing: a small piece of text that users provide to
+prove their identity.
+
+#### What makes a good password?
+
+A "good password" may mean different things to different people. I will
+assert that a good password has the following properties:
+
+-   high entropy: hard to guess for machines
+-   transferable: easy to communicate for humans or transfer across
+    various protocols for computers
+-   memorable: easy to remember for humans
+
+High entropy means that the password should be unpredictable to an
+attacker, for all practical purposes. It is tempting (and not uncommon)
+to choose a password based on something else that you know, but
+unfortunately those choices are likely to be guessable, no matter how
+"secret" you believe it is. Yes, with enough effort, an attacker can
+figure out your birthday, the name of your first lover, your mother's
+maiden name, where you were last summer, or other secrets people think
+they have.
+
+The only solution here is to use a password randomly generated with
+enough randomness or "entropy" that brute-forcing the password will be
+practically infeasible. Considering that a modern off-the-shelf graphics
+card can guess millions of passwords per second using freely available
+software like [hashcat](https://www.hashcat.net/hashcat/), the typical
+requirement of "8 characters" is not considered enough anymore. With
+proper hardware, a powerful rig can crack such passwords offline within
+about a day. Even though a recent [US National Institute of Standards
+and Technology (NIST)](https://www.nist.gov/) draft still
+[recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-authenticators)
+a minimum of eight characters, we now more often hear recommendations of
+[twelve
+characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
+or [fourteen
+characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
+
+A password should also be easily "transferable". Some characters, like
+`&` or `!`, have special meaning on the web or the shell and can wreak
+havoc when transferred. Certain software also has policies of *refusing*
+(or requiring!) some special characters exactly for that reason. Weird
+characters also make it harder for humans to communicate passwords
+across voice channels or different cultural backgrounds. In a more
+extreme example, the popular Signal software even resorted to [using
+only digits](https://whispersystems.org/blog/safety-number-updates/) to
+transfer key fingerprints. They outlined that numbers are "*easy to
+localize*" (as opposed to words, which are language-specific) and
+"*visually distinct*".
+
+But the critical piece is the "memorable" part: it is trivial to
+generate a random string of characters, but those passwords are hard for
+humans to remember. As [xkcd noted](https://xkcd.com/936/),
+"*through 20 years of effort, we've successfully trained everyone
+to use passwords that are hard for human to remember but easy for
+computers to guess*". It explains how a series of words is a
+better password than a single word with some characters replaced.
+
+Obviously, you should not need to remember all passwords. Indeed, you
+may store some in password managers (which we'll look at in another
+article) or write them down in your wallet. In those cases, what you
+need is not a password, but something I would rather call a "token", or,
+as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
+"*high entropy, compact, and transferable string*". Certain APIs are
+specifically crafted to use tokens. [OAuth](https://oauth.net/), for
+example, generates "access tokens" that are random strings that give
+access to services. But in our discussion, we'll use the term "token" in
+a broader sense.
+
+Notice how we removed the "memorable" property and added the "compact"
+one: we want to efficiently convert the most entropy into the shortest
+password possible, to work around possibly limiting password policies.
+For example, some bank cards only allow 5-digit security PINs and most
+web sites have an upper limit in the password length. The "compact"
+property applies less to "passwords" than tokens, because I assume that
+you will only use a password in select places: your password manager,
+SSH and OpenPGP keys, your computer login, and encryption keys.
+Everything else should be in a password manager. Those tools are
+generally under your control and should allow large enough passwords
+that the compact property is not particularly important.
+
+#### Generating secure passwords
+
+We'll look now at how to generate a strong, transferable, and memorable
+password. These are most likely the passwords you will deal with most of
+the time, as security tokens used in other settings should actually
+never show up on screen: they should be copy-pasted or automatically
+typed in forms. The password generators described here are all operated
+from the command line. Password managers often have embedded password
+generators, but usually don't provide an easy way to generate a password
+for the vault itself.
+
+The previously mentioned xkcd cartoon is probably a common cultural
+reference in the security crowd and I often use it to explain how to
+choose a good passphrase. It turns out that someone actually implemented
+xkcd author Randall Munroe's suggestion into a program called
+[xkcdpass](https://pypi.python.org/pypi/xkcdpass/):
+
+        $ xkcdpass
+        estop mixing edelweiss conduct rejoin flexitime
+
+In verbose mode, it will show the actual entropy of the generated
+passphrase:
+
+        $ xkcdpass -V
+        The supplied word list is located at /usr/lib/python3/dist-packages/xkcdpass/static/default.txt.
+        Your word list contains 38271 words, or 2^15.22 words.
+        A 6 word password from this list will have roughly 91 (15.22 * 6) bits of entropy,
+        assuming truly random word selection.
+        estop mixing edelweiss conduct rejoin flexitime
+
+Note that the above password has 91 bits of entropy, which is about what
+a fifteen-character password would have, if chosen at random from
+uppercase, lowercase, digits, and ten symbols:
+
+        log2((26 + 26 + 10 + 10)^15) = approx. 92.548875
+
+It's also interesting to note that this is closer to the entropy of a
+fifteen-letter base64 encoded password: since each character is six
+bits, you end up with 90 bits of entropy. xkcdpass is scriptable and
+easy to use. You can also customize the word list, separators, and so on
+with different command-line options. By default, xkcdpass uses the [2 of
+12](http://wordlist.aspell.net/12dicts-readme/#nof12) word list from [12
+dicts](http://wordlist.aspell.net/12dicts/), which is not specifically
+geared toward password generation but has been curated for "common
+words" and words of different sizes.
+
+Another option is the [diceware system](http://diceware.com/). Diceware
+works by having a word list in which you look up words based on dice
+rolls. For example, rolling the five dice "1 4 2 1 4" would give the
+word "bilge". By rolling those dice five times, you generate a five word
+password that is both memorable and random. Since paper and dice do not
+seem to be popular anymore, someone wrote that as an actual program,
+aptly called [diceware](https://github.com/ulif/diceware). It works in a
+similar fashion, except that passwords are not space separated by
+default:
+
+        $ diceware
+        AbateStripDummy16thThanBrock
+
+Diceware can obviously change the output to look similar to xkcdpass,
+but can also accept actual dice rolls for those who do not trust their
+computer's entropy source:
+
+        $ diceware -d ' ' -r realdice -w en_orig
+        Please roll 5 dice (or a single dice 5 times).
+        What number shows dice number 1? 4
+        What number shows dice number 2? 2
+        What number shows dice number 3? 6
+        [...]
+        Aspire O's Ester Court Born Pk
+
+The diceware software ships with a few word lists, and the default list
+has been deliberately created for generating passwords. It is derived
+from the standard diceware list with additions from the [SecureDrop
+project](https://securedrop.org/). Diceware ships with the [EFF word
+list](https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases)
+that has words chosen for better recognition, but it is not enabled by
+default, even though diceware recommends using it when generating
+passwords with dice. That is because the EFF list was added [later
+on](https://github.com/ulif/diceware/issues/26). The project is
+currently [considering](https://github.com/ulif/diceware/issues/33)
+making the EFF list be the default.
+
+One disadvantage of diceware is that it doesn't actually show how much
+entropy the generated password has — those interested need to compute it

(fichier de différences tronqué)
move history out into a separate article
diff --git a/blog/hashers-history.mdwn b/blog/hashers-history.mdwn
new file mode 100644
index 0000000..0b05a85
--- /dev/null
+++ b/blog/hashers-history.mdwn
@@ -0,0 +1,201 @@
+A short history of password hashers
+-----------------------------------
+
+Since the concept is so old, it may be useful to go over a
+short history of notable password hashers, before we go
+into issues specific to their implementation.
+
+[Nic Wolff](http://angel.net/~nic/passwd.current.html)
+[claims](https://news.ycombinator.com/item?id=12892655) to be the
+first to have written such a program, all the
+[way back in 2003](http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html). Back
+then the hashing algorithm was [MD5](https://en.wikipedia.org/wiki/MD5), although Wolff has now updated the
+algorithm to use [SHA-1](https://en.wikipedia.org/wiki/SHA-1) and still maintains his webpage for public
+use. Another ancient but unrelated implementation, is the Standford
+University Applied Cryptography's
+[pwdhash](https://crypto.stanford.edu/PwdHash) software. That
+implementation was
+[published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/)
+and unfortunately, that implementation was not updated and still uses
+MD5 as an hashing algorithm, but at least it uses
+[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)
+to generate tokens, which makes the use of
+[rainbow tables](https://en.wikipedia.org/wiki/Rainbow_table)
+impractical. Those implementations are the simplest
+password hashers: the inputs are simply the site URL and a
+password. So the algorithms are, basically, for Wolff's:
+
+    token = base64(SHA1(password + domain))
+
+And for [Standford's PwdHash](https://www.pwdhash.com/hashed-password.js):
+
+    token = base64(HMAC(MD5, password, domain)))
+
+Another unrelated implementation that is still around is
+[supergenpass](https://chriszarate.github.io/supergenpass/) is a
+bookmarklet that was
+[created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
+originally using MD5 as well but now supports SHA512 now although
+still
+[limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
+and still
+[defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
+with
+[not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
+(10). Note that Chris Zarate, the supergenpass author, actually
+credits Nic Wolff as the inspiration for his
+implementation. Supergenpass is still in active development and is
+available for the browser (as a
+[bookmarklet](https://chriszarate.github.io/supergenpass/)) or mobile
+(as an
+[webpage](https://chriszarate.github.io/supergenpass/mobile/)). Supergenpass
+allows you to modify the password length, but also add an extra
+profile password which adds to the secret and generates a personalized
+[identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
+prevent phishing but it also introduces an interesting protection,
+only found later in Password Hasher Plus. So the
+[Supergenpass algorithm](https://github.com/chriszarate/supergenpass-lib/blob/eb9ee92050813d498229bfe0e6ccbcb87124cf90/src/lib/generate.js#L32) looks something like this:
+
+    token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
+
+Anothor popular implementation is the Wiijo password hasher,
+[created around 2006](http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/).
+It was probably the first shipped as a
+[browser extension](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
+which greatly improved the security of the product as users didn't
+have to continually download the software on the fly. Wiijo's
+algorithm also improved on the above algorithms, as it uses HMAC-SHA1
+instead of plain SHA-1 or HMAC-MD5, which makes it harder to recover
+the plaintext. Password hasher allows you to set different password
+policies (use digits, punctuation, mixed case, special characters and
+password length) and saves the site names it uses for future
+reference. It also happens that the Wiijo password hasher, in turn,
+took its inspiration on *different* project,
+[hashapass.com](http://www.hashapass.com/),
+[created in 2006](http://web.archive.org/web/20060702050519/http://www.hashapass.com/)
+and also based on
+HMAC-SHA-1. [Indeed](http://www.hashapass.com/en/cmd.html), hashapass
+"can easily be generated on almost any modern Unix-like system using
+the following command line pattern":
+
+    echo -n parameter \
+    | openssl dgst -sha1 -binary -hmac password \
+    | openssl enc -base64 \
+    | cut -c 1-8
+
+So the
+[algorithm](https://addons.mozilla.org/en-US/firefox/files/browse/140427/file/chrome/content/passhash-common.js#L298)
+here is obviously:
+
+    token = base64(HMAC(SHA1, password, domain + ":" + counter)))
+
+... although in the case of Password Hasher, there is a special
+routine that takes the token and inserts random characters in locations
+determined by the sum of the values of the characters in the token.
+
+Years later, in 2010, Eric Woodruff ported the Wiijo "password hasher"
+to Chrome and called it
+[Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd?hl=en).
+Like the original password hasher, the "plus" version also keeps those
+settings in the extension and uses HMAC-SHA-1 to generate the
+password, as it is designed to be backwards-compatible with the Wiijo
+password hasher. Woodruff did add an one interesting feature: a
+profile-specific secret key that gets mixed in to create the security
+token. Stealing the master password is therefore not enough to
+generate tokens anymore. This solves one security concern with
+Password Hasher: an hostile page could watch your keystrokes and steal
+your master password and use it to derive passwords on other
+sites. Having a profile-specific secret key, not accessible to the
+site's Javascript works around that issue, but one could argue that
+typing the master password directly in the password file, while
+convenient, is probably just a bad idea in retrospect. The final
+algorithm looks something like:
+
+    token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
+
+Honestly, that seems rather strange, but it's what I read from the
+source code, which is available only after decompressing the extension
+nowadays. I would have expected the simplest version:
+
+    token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain))
+
+Password Hasher Plus then takes the token and applies the same
+special character insertion routine as the Password Hasher.
+
+Last year, [Guillaume Vincent](http://guillaumevincent.com/) a french
+self-described "humanist and scuba diving fan" released the
+[lesspass](https://lesspass.com/) extension for Chrome, Firefox and
+Android. Lesspass introduces numerous interesting functionalities. It
+is probably the first to include a
+[commandline version](https://github.com/lesspass/cli). It also
+[uses](https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4) a
+more robust key derivation algorithm
+([PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)) and takes into
+account the username on the site, allowing multi account support. The
+original release (version 1) used only 8192 rounds which is now
+considered too low. In the
+[bug report](https://github.com/lesspass/lesspass/issues/38) it was
+interesting to note that LessPass couldn't do the usual practice of
+running the key derivation for 1 second to determine the number of
+rounds needed as the results need to be deterministic. At first
+glance, the LessPass source code seems
+[clear and easy to read](https://github.com/lesspass/core/blob/master/src/v2.js)
+at first glance which is always a good sign, but of course, the devil
+is in the details. One key feature it is missing from Password Hasher
+Plus is the profile-specific seed, although one could argue it should
+be more difficult, if not impossible, for a webpage Javascript script
+to steal keystrokes from a browser extension.
+
+The [algorithm][] then gets a little more interesting:
+
+    entropy = PBKDF2(SHA256, masterPassword, domain + username + counter, rounds, length)
+    where rounds = 10000 and length = 32
+
+[algorithm]: https://github.com/lesspass/core/blob/24c339e/src/v2.js#L15
+
+(Confused by the pbkdg2 implementation here:
+https://github.com/lesspass/core/blob/master/src/pbkdf2.js - ImportKey
+doesn't support PBKDF2?? it's just something to extract key material?
+and then later, why AES-CTR??)
+
+There is also a
+[lesspass-specific character picking routing](https://github.com/lesspass/core/blob/24c339e/src/v2.js#L78)
+(ie. not base64, and different from the original Password Hasher
+algorithm).
+
+A review of password hashers would hardly be complete without
+mentioning the [Master Password](http://masterpasswordapp.com/),
+probably the
+[definite algorithm](http://masterpasswordapp.com/algorithm.html) for
+password hashers. While the applications surrounding the project are
+not as refined (there is no web browser plugin and the
+[web interface](https://js.masterpasswordapp.com/) can't be easily
+turned into a bookmarklet), the algorithm has been well developed. In all the
+password managers reviewed here, Master Password uses one of the
+strongest key derivation algorithms out there,
+[scrypt](https://en.wikipedia.org/wiki/Scrypt):
+
+    key = scrypt( password, salt, cost, size, parallelization, length )
+    where
+    salt = "com.lyndir.masterpassword" + len(username) + name
+    cost = 32768
+    size = 8
+    parallelization = 2
+    length = 64
+    entropy = hmac-sha256(key, "com.lyndir.masterpassword" + len(domain) + domain + counter )
+
+Master Password the uses one of 6 sets of "templates" specially
+crafted to be "easy for a user to read from a screen and type using a
+keyboard or smartphone" and "compatible with most site's password
+policies". For example, the default template mixes vowels,
+consonants, numbers and symbols, but carefully avoiding possibly
+visibly similar characters like `O` and `0` or `i` and `1` (although
+it does mix `1` and `l`, oddly enough).
+

(Diff truncated)
add quote from an article i read
diff --git a/sigs.fortune b/sigs.fortune
index c0d3956..33bb940 100644
--- a/sigs.fortune
+++ b/sigs.fortune
@@ -1041,3 +1041,8 @@ Si les élections n'étaient pas indispensables à la prospérité du
 capital, on ne nous les servirait pas partout, toujours, à coup de
 fric, à coup de flics.
                         - René Binamé
+%
+The most prudent course for any society is to start from the
+assumption that the Internet should be fundamentally outside the
+domain of capital.
+                        - The Internet's Unholy Marriage to Capitalism

new changes from LWN
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 4359267..360eb2f 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -5,10 +5,10 @@ As we noted in an [earlier article](/Articles/713806/), passwords are a
 liability and we'd prefer to get rid of them, but the current reality is
 that we do use a plethora of passwords in our daily lives. This problem
 is especially acute for technology professionals, particularly system
-administrators, that have to manage a lot of different machines. But it
+administrators, who have to manage a lot of different machines. But it
 also affects regular users who still use a large number of passwords,
-from their online bank credentials to their favorite social networking
-site. Despite the [remarkable memory capacity of the human
+from their online bank to their favorite social-networking site. Despite
+the [remarkable memory capacity of the human
 brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
 humans are actually terrible at recalling even short sets of arbitrary
 characters with the precision needed for passwords.
@@ -25,10 +25,10 @@ But there is a large variety of password managers out there, so which
 one should we be using? At my previous job, an inventory was done of
 about [40 different free-software password
 managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
-from the last eight years, in different stages of development and of
-varying quality. So, obviously, this article will not be exhaustive, but
-instead focus on a smaller set of some well-known options that may be
-interesting to readers.
+in different stages of development and of varying quality. So,
+obviously, this article will not be exhaustive, but instead focus on a
+smaller set of some well-known options that may be interesting to
+readers.
 
 #### KeePass: the popular alternative
 
@@ -39,21 +39,21 @@ popular free-software password manager of this kind is probably
 
 An important feature of KeePass is the ability to auto-type passwords in
 forms, most notably in web browsers. This feature makes KeePass really
-easy to use, especially considering it also supports global keybindings
-to access passwords. KeePass databases are also designed for
-simultaneous access by multiple users for example using a shared network
-drive.
+easy to use, especially considering it also supports global key bindings
+to access passwords. KeePass databases are designed for simultaneous
+access by multiple users, for example, using a shared network drive.
 
-KeePass is a graphical interface written in C\#, so it uses the Mono
-framework in Linux. A separate project, called
+KeePass has a graphical interface written in C\#, so it uses the Mono
+framework on Linux. A separate project, called
 [KeePassX](https://www.keepassx.org/) is a clean-room implementation
 written in C++ using the Qt framework. Both support the
 [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and
 [Twofish](https://en.wikipedia.org/wiki/Twofish) encryption algorithms,
 although KeePass recently added support for the
-[ChaCha20](https://en.wikipedia.org/wiki/ChaCha20) cipher. AES key
-derivation is also used to generate the actual encryption key for the
-database, but the latest release of KeePass also added using
+[ChaCha20](https://en.wikipedia.org/wiki/ChaCha20) cipher. AES [key
+derivation](http://keepass.info/help/base/security.html#secdictprotect)
+is used to generate the actual encryption key for the database, but the
+latest release of KeePass also added using
 [Argon2](https://en.wikipedia.org/wiki/Argon2), which was the winner of
 the July 2015 [password-hashing
 competition](https://password-hashing.net/). Both programs are more or
@@ -66,7 +66,7 @@ features that are present in KeePass but missing from KeePassX like:
 
 -   auto-type on Linux, Mac OS, and Windows
 -   database merging — which allows multi-user support
--   favicon support
+-   using the web site's favicon in the interface
 
 So far, the maintainers of KeePassXC seem to be open to [re-merging the
 project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
@@ -78,8 +78,8 @@ requests and only one pull request was merged since the last release,
 which was 2.0.3 in September 2016.
 
 While KeePass and derivatives allow multiple users to access the same
-database through the merging process, they do not support multi-tiered
-access in a single database. This may be a limiting factor for larger
+database through the merging process, they do not support multi-party
+access to a single database. This may be a limiting factor for larger
 organizations, where you may need, for example, a different password set
 for different technical support team levels. The solution in this case
 is to use separate databases for each team, with each team using a
@@ -127,16 +127,18 @@ feature.
 
 Furthermore, there is a [tomb
 plugin](https://github.com/roddhjav/pass-tomb) for `pass` that encrypts
-the password store in a LUKS container, although it requires explicitly
-opening and closing the container, which makes it only marginally better
-than using full disk encryption system-wide. One could also argue that
-password file names do not hold secret information, only the site name
-and username, perhaps, and that doesn't require secrecy. I do believe
-those should be kept secret, however, as they could be used to discover
-(or prove) which sites you have access to and then used to perform other
-attacks. One could draw a parallel with the SSH `known_hosts` file,
-which used to be plain text but is now hashed so that hosts are more
-difficult to discover.
+the password store in a
+[LUKS](https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup) container
+(called a "[tomb](https://github.com/dyne/Tomb)"), although it requires
+explicitly opening and closing the container, which makes it only
+marginally better than using full disk encryption system-wide. One could
+also argue that password file names do not hold secret information, only
+the site name and username, perhaps, and that doesn't require secrecy. I
+do believe those should be kept secret, however, as they could be used
+to discover (or prove) which sites you have access to and then used to
+perform other attacks. One could draw a parallel with the SSH
+`known_hosts` file, which used to be plain text but is now hashed so
+that hosts are more difficult to discover.
 
 Also, sharing a database for multi-user support will require some sort
 of file-sharing mechanism. Given the integrated Git support, this will
@@ -166,8 +168,8 @@ subdirectories:
          create mode 100644 Ateam/.gpg-id
 
 The above will configure `pass` to encrypt the passwords in the `Ateam`
-directory for `me@example.com` and `joelle@example.com`. `pass` depends
-on GnuPG to do the right thing when encrypting files and how those
+directory for me@example.com and joelle@example.com. `pass` depends on
+GnuPG to do the right thing when encrypting files and how those
 identities are treated is entirely delegated to GnuPG's default
 configuration. This could lead to [problems](/Articles/697417/) if
 arbitrary keys can be injected into your key ring, which could confuse
@@ -246,8 +248,8 @@ attacks, which is mentioned below.
 
 Finally, because browser-based managers generally lack a proper password
 generator, users may fail to use properly generated passwords, so they
-can then be easily broken. A password generator may actually be
-implemented soon in Firefox, according to this [feature
+can then be easily broken. A password generator has been requested for
+Firefox, according to this [feature
 request](https://bugzilla.mozilla.org/show_bug.cgi?id=376674) opened in
 2007, and there *is* a [password generator in
 Chrome](https://www.chromium.org/developers/design-documents/password-generation),
@@ -266,7 +268,7 @@ and therefore doesn't leak the name of the entries by default. In
 addition to copy/paste, Assword also supports automatically entering
 passphrases in fields using the
 [xdo](https://www.semicomplete.com/projects/xdotool) library. Like
-`pass`, it also uses GnuPG to encrypt passphrases. According to Assword
+`pass`, it uses GnuPG to encrypt passphrases. According to Assword
 maintainer Daniel Kahn Gillmor in email, the main issue with Assword is
 "interaction between generated passwords and insane password policies".
 He gave the example of the Time-Warner Cable registration form that
@@ -274,13 +276,13 @@ requires, among other things, "letters and numbers, between 8 and 16
 characters and not repeat the same characters 3 times in a row".
 
 Another well-known password manager is the commercial
-[LastPass](https://en.wikipedia.org/wiki/Lastpass) service which
+[LastPass](https://lastpass.com/) service which
 [released](https://blog.lastpass.com/2014/10/open-sourced-lastpass-command-line-application-now-available.html/)
 a free-software command-line client called
 [lastpass-cli](https://github.com/lastpass/lastpass-cli) about three
-years ago. Unfortunately, the server software of the
-[lastpass.com](https://lastpass.com/) service is still proprietary. And
-given that LastPass has had at least [two serious security
+years ago. Unfortunately, the server software of the lastpass.com
+service is still proprietary. And given that LastPass has had at least
+[two serious security
 breaches](https://en.wikipedia.org/wiki/LastPass#Security_issues) since
 that release, one could legitimately question whether this is a viable
 solution for storing important secrets.

first internal draft
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index de3be2a..4359267 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -1,370 +1,364 @@
-A review of password managers
------------------------------
-
-As we discussed in the
-[previous article](https://lwn.net/Articles/713806/), passwords are a
-liability and we'd prefer to get rid of them. But the current reality
-is that we do use a plethora of passwords in our daily lives. This
-problem is especially acute for technology professionals, particularly
-system administrators that have to manage a lot of different
-machines. But it also affects regular users who still use a large
-number of passwords, from their online bank credentials to their
-favorite social networking site. Despite the
-[remarkable memory capacity of the human brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
+A look at password managers
+===========================
+
+As we noted in an [earlier article](/Articles/713806/), passwords are a
+liability and we'd prefer to get rid of them, but the current reality is
+that we do use a plethora of passwords in our daily lives. This problem
+is especially acute for technology professionals, particularly system
+administrators, that have to manage a lot of different machines. But it
+also affects regular users who still use a large number of passwords,
+from their online bank credentials to their favorite social networking
+site. Despite the [remarkable memory capacity of the human
+brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
 humans are actually terrible at recalling even short sets of arbitrary
-characters with the precision needed to use passwords. Humans, in
-short, are proving to be bad at generating high entropy and unique
-passwords that they can remember.
+characters with the precision needed for passwords.
 
 Therefore humans [reuse passwords](https://xkcd.com/792/), make them
-trivial or guessable, write them down on little paper notes and
-stick them on their screens or just reset them by email every
-time. Our memory is undeniably failing us and we need help, which is
-where password managers come in. Password managers allow users to
-store an arbitrary number of passwords and just remember a single
-password to unlock them all.
+trivial or guessable, write them down on little paper notes and stick
+them on their screens, or just reset them by email every time. Our
+memory is undeniably failing us and we need help, which is where
+password managers come in. Password managers allow users to store an
+arbitrary number of passwords and just remember a single password to
+unlock them all.
 
 But there is a large variety of password managers out there, so which
-one should we be using? At my previous job, we have inventoried about
-[40 different free software password managers][] in the last 8 years,
-in different stages of development and quality. So obviously, this
-review will not be exhaustive, but instead focus on a smaller set of
-some well known alternatives that may be interesting to our
-readers.
+one should we be using? At my previous job, an inventory was done of
+about [40 different free-software password
+managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
+from the last eight years, in different stages of development and of
+varying quality. So, obviously, this article will not be exhaustive, but
+instead focus on a smaller set of some well-known options that may be
+interesting to readers.
 
-[40 different free software password managers]: https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison
+#### KeePass: the popular alternative
 
-KeePass: the popular alternative
---------------------------------
-
-The most commonly used password manager design pattern is to store
+The most commonly used password-manager design pattern is to store
 passwords in a file that is encrypted and password-protected. The most
-popular free software password manager of this kind is probably
-KeePass.
+popular free-software password manager of this kind is probably
+[KeePass](http://keepass.info/).
 
-An important feature of KeePass is the ability to auto-type passwords
-in forms, most notably in web browsers. This feature makes KeePass really
-easy to use, especially considering it also supports global
-keybindings to access passwords. KeePass databases are also designed
-for simultaneous access by multiple users for example using a shared
-network drive. 
+An important feature of KeePass is the ability to auto-type passwords in
+forms, most notably in web browsers. This feature makes KeePass really
+easy to use, especially considering it also supports global keybindings
+to access passwords. KeePass databases are also designed for
+simultaneous access by multiple users for example using a shared network
+drive.
 
-KeePass is a graphical interface written in C#, so it uses the Mono
+KeePass is a graphical interface written in C\#, so it uses the Mono
 framework in Linux. A separate project, called
-[KeePassX](https://www.keepassx.org/) is a cleanroom implementation
+[KeePassX](https://www.keepassx.org/) is a clean-room implementation
 written in C++ using the Qt framework. Both support the
 [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and
-[Twofish](https://en.wikipedia.org/wiki/Twofish) encryption
-algorithms, although KeePass recently added support for the
+[Twofish](https://en.wikipedia.org/wiki/Twofish) encryption algorithms,
+although KeePass recently added support for the
 [ChaCha20](https://en.wikipedia.org/wiki/ChaCha20) cipher. AES key
 derivation is also used to generate the actual encryption key for the
 database, but the latest release of KeePass also added using
-[Argon2](https://en.wikipedia.org/wiki/Argon2) the winner of the July
-2015
-[password hashing competition](https://password-hashing.net/). Both
-programs are more or less equivalent, although the original KeePass
-seem to be more featureful in general.
-
-I should finally note that the KeePassX project has recently been
-forked into another project now called
-[KeePassXC](https://keepassxc.org/) which implement a set of new
-features present in KeePass but missing from KeePassX like:
-
-* autotype on Linux, Mac OS and Windows
-* database merging - which allows multi-user support
-* favicon support
-
-So far the maintainers of KeePassXC are open to
-[re-merging the project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
-"if the original maintainer of KeePassX in the future will be more
-active and will accept our merge and changes". I could confirm that,
-at the time of writing, the original
-[KeePassX project](https://github.com/keepassx/keepassx) now has 79
-pending pull requests and only one pull request was merged since the
-last 2.0.3 release in september.
+[Argon2](https://en.wikipedia.org/wiki/Argon2), which was the winner of
+the July 2015 [password-hashing
+competition](https://password-hashing.net/). Both programs are more or
+less equivalent, although the original KeePass seem to have more
+features in general.
+
+The KeePassX project has recently been forked into another project now
+called [KeePassXC](https://keepassxc.org/) that implements a set of new
+features that are present in KeePass but missing from KeePassX like:
+
+-   auto-type on Linux, Mac OS, and Windows
+-   database merging — which allows multi-user support
+-   favicon support
+
+So far, the maintainers of KeePassXC seem to be open to [re-merging the
+project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
+"<span>if the original maintainer of KeePassX in the future will be more
+active and will accept our merge and changes</span>". I can confirm
+that, at the time of writing, the original [KeePassX
+project](https://github.com/keepassx/keepassx) now has 79 pending pull
+requests and only one pull request was merged since the last release,
+which was 2.0.3 in September 2016.
 
 While KeePass and derivatives allow multiple users to access the same
 database through the merging process, they do not support multi-tiered
 access in a single database. This may be a limiting factor for larger
-organizations, where you may need, for example, a different password
-set for different technical support team levels. The solution in this
-case is to use a separate databases for each team, with each team
-using a different shared secret.
+organizations, where you may need, for example, a different password set
+for different technical support team levels. The solution in this case
+is to use separate databases for each team, with each team using a
+different shared secret.
 
-Pass: the standard password manager?
-------------------------------------
+#### Pass: the standard password manager?
 
 I am currently using [password-store](https://www.passwordstore.org/),
-or `pass`, as a password manager. It aims to be "the standard unix
-password manager". `pass` is a GnuPG-based password manager that
+or `pass`, as a password manager. It aims to be "<span>the standard Unix
+password manager</span>". `pass` is a GnuPG-based password manager that
 features a surprising number of features given its small size:
 
-* copy-paste support
-* git integration
-* multi-user/group support
-* pluggable extensions (in the upcoming 1.7 release)
+-   copy-paste support
+-   Git integration
+-   multi-user/group support
+-   pluggable extensions (in the upcoming 1.7 release)
 
-The commandline interface is simple to use and intuitive. The
+The command-line interface is simple to use and intuitive. The
 following, will, for example, create a pass repository, a 20 character
 password for your LWN account and copy it to the clipboard:
 
-    pass init
-    pass generate -c lwn 20
+        $ pass init
+        $ pass generate -c lwn 20
 
 The main issue with `pass` is that it doesn't encrypt the *name* of
-those entries: if someone would compromise my machine, they could
-easily see which sites I have access to simply by listing the password
+those entries: if someone were to compromise my machine, they could
+easily see which sites I have access to simply by listing the passwords
 stored in `~/.password-store`. This is a deliberate design decision by

(fichier de différences tronqué)
move blurb from managers article
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 030c9a3..45bd141 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -1,3 +1,28 @@
+
+When giving security training, I often recommend people use three
+different strategies for passwords:
+
+ 1. use a "stateless password manager" in the browser, or use the
+    "master key feature" of browsers to store passwords for most
+    (unimportant) websites
+ 2. use a password manager for more critical passwords (online bank
+    account, main email account, etc)
+ 3. remember a small set of critical passwords (bank card PIN,
+    password manager passwords)
+
+Unfortunately, a recent code review of the stateless password manager
+I was using
+([Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd/related?hl=en))
+made me change my mind about that recommendation, which I will explain
+in a later article. Furthermore, browser-based password managers have
+their own set of issues covered later in this article. Therefore, for
+users that can afford having a trusted computer regularly accessible,
+my recommendation is generally:
+
+ 1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
+ 2. use a real password manager for the rest
+
+
 This article is the second in the series of three about passwords.
 
  1. The first article covers passwords, how to generate them and a

final review before sending to jake
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 499faf1..de3be2a 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -2,15 +2,14 @@ A review of password managers
 -----------------------------
 
 As we discussed in the
-[previous article](https://lwn.net/Articles/713806/), passwords are
-terrible and we'd prefer to get rid of them. But the current reality
-is that we do use a plethora of passwords in our daily lives on the
-internet. This problem is especially acute for technology
-professionals, particularly system administrators that have to manage
-a lot of different machines. But it also affects regular users who
-still use a large number of passwords in their daily lives, from their
-online bank credentials to their favorite social networking
-site. Despite the
+[previous article](https://lwn.net/Articles/713806/), passwords are a
+liability and we'd prefer to get rid of them. But the current reality
+is that we do use a plethora of passwords in our daily lives. This
+problem is especially acute for technology professionals, particularly
+system administrators that have to manage a lot of different
+machines. But it also affects regular users who still use a large
+number of passwords, from their online bank credentials to their
+favorite social networking site. Despite the
 [remarkable memory capacity of the human brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
 humans are actually terrible at recalling even short sets of arbitrary
 characters with the precision needed to use passwords. Humans, in
@@ -20,42 +19,22 @@ passwords that they can remember.
 Therefore humans [reuse passwords](https://xkcd.com/792/), make them
 trivial or guessable, write them down on little paper notes and
 stick them on their screens or just reset them by email every
-time. Our memory is undeniably failing us and we need help.
-
-When giving security training, I often recommend people use three
-different strategies for passwords:
-
- 1. use a "stateless password manager" in the browser, or use the
-    "master key feature" of browsers to store passwords for most
-    (unimportant) websites
- 2. use a password manager for more critical passwords (online bank
-    account, main email account, etc)
- 3. remember a small set of critical passwords (bank card PIN,
-    password manager passwords)
-
-Unfortunately, a recent code review of the stateless password manager
-I was using
-([Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd/related?hl=en))
-made me change my mind about that recommendation, which I will explain
-in a later article. Furthermore, browser-based password managers have
-their own set of issues covered later in this article. Therefore, for
-users that can afford having a trusted computer regularly accessible,
-my recommendation is generally:
-
- 1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
- 2. use a real password manager for the rest
+time. Our memory is undeniably failing us and we need help, which is
+where password managers come in. Password managers allow users to
+store an arbitrary number of passwords and just remember a single
+password to unlock them all.
 
 But there is a large variety of password managers out there, so which
 one should we be using? At my previous job, we have inventoried about
 [40 different free software password managers][] in the last 8 years,
 in different stages of development and quality. So obviously, this
 review will not be exhaustive, but instead focus on a smaller set of
-the most well known alternative that may be interesting to our
+some well known alternatives that may be interesting to our
 readers.
 
 [40 different free software password managers]: https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison
 
-Keepass: the popular alternative
+KeePass: the popular alternative
 --------------------------------
 
 The most commonly used password manager design pattern is to store
@@ -70,15 +49,18 @@ keybindings to access passwords. KeePass databases are also designed
 for simultaneous access by multiple users for example using a shared
 network drive. 
 
-Keepass is a graphical interface written in C#, so it uses the Mono
+KeePass is a graphical interface written in C#, so it uses the Mono
 framework in Linux. A separate project, called
 [KeePassX](https://www.keepassx.org/) is a cleanroom implementation
-written on C++ and QT. Both support the AES and Twofish encryption
-algorithms, although Keepass recently added support for the ChaCha20
-cipher. AES key derivation is also used to generate the actual
-encryption key for the database, but the latest release of KeePass
-also added using [Argon2](https://en.wikipedia.org/wiki/Argon2) the
-winner of the July 2015
+written in C++ using the Qt framework. Both support the
+[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and
+[Twofish](https://en.wikipedia.org/wiki/Twofish) encryption
+algorithms, although KeePass recently added support for the
+[ChaCha20](https://en.wikipedia.org/wiki/ChaCha20) cipher. AES key
+derivation is also used to generate the actual encryption key for the
+database, but the latest release of KeePass also added using
+[Argon2](https://en.wikipedia.org/wiki/Argon2) the winner of the July
+2015
 [password hashing competition](https://password-hashing.net/). Both
 programs are more or less equivalent, although the original KeePass
 seem to be more featureful in general.
@@ -86,7 +68,7 @@ seem to be more featureful in general.
 I should finally note that the KeePassX project has recently been
 forked into another project now called
 [KeePassXC](https://keepassxc.org/) which implement a set of new
-features present in KeePass like:
+features present in KeePass but missing from KeePassX like:
 
 * autotype on Linux, Mac OS and Windows
 * database merging - which allows multi-user support
@@ -95,15 +77,19 @@ features present in KeePass like:
 So far the maintainers of KeePassXC are open to
 [re-merging the project](https://github.com/keepassxreboot/keepassxc/issues/43#issuecomment-254045934)
 "if the original maintainer of KeePassX in the future will be more
-active and will accept our merge and changes". I could confirm that
-the original [KeePassX project](https://github.com/keepassx/keepassx)
-now has 79 pending pull requests and only one pull request was merged
-since the last 2.0.3 release in september.
-
-KeePass and derivatives do not support multi-tiered access in a single
-database. To restrict access between teams, operators will need to use
-separate databases for each team, with each team using a different
-shared secret.
+active and will accept our merge and changes". I could confirm that,
+at the time of writing, the original
+[KeePassX project](https://github.com/keepassx/keepassx) now has 79
+pending pull requests and only one pull request was merged since the
+last 2.0.3 release in september.
+
+While KeePass and derivatives allow multiple users to access the same
+database through the merging process, they do not support multi-tiered
+access in a single database. This may be a limiting factor for larger
+organizations, where you may need, for example, a different password
+set for different technical support team levels. The solution in this
+case is to use a separate databases for each team, with each team
+using a different shared secret.
 
 Pass: the standard password manager?
 ------------------------------------
@@ -116,7 +102,7 @@ features a surprising number of features given its small size:
 * copy-paste support
 * git integration
 * multi-user/group support
-* pluggable extensions
+* pluggable extensions (in the upcoming 1.7 release)
 
 The commandline interface is simple to use and intuitive. The
 following, will, for example, create a pass repository, a 20 character
@@ -137,6 +123,19 @@ item has the advantage of shell completion, using version control,
 already alternative password managers that
 [use a single (encrypted) database]".
 
+Furthermore, there is a
+[tomb plugin](https://github.com/roddhjav/pass-tomb) that encrypts the
+password store in a LUKS container, although it requires to
+explicitely open and close the container which makes it only
+marginally better than using full disk encryption system-wide. One
+could also argue that password file names do not hold secret
+information, only the site name and username, maybe, and that doesn't
+deserve secrecy. I do believe those should be kept secret however, as
+they could be used to discover (or prove) which sites you have access
+to and then leveraged to perform other attacks. One could draw a
+parallel with the SSH `known_hosts` file, which used to be plain text
+but are now hashed so they are more difficult to discover.
+
 Also, sharing a database for multi-user support will require some sort
 of file-sharing mechanism. Given the integrated git support, this will
 likely involve setting up a private git repository for your team,
@@ -176,7 +175,7 @@ recommend using full key fingerprints instead of user identifiers.
 
 Regarding the actual encryption algorithms used, GnuPG 1.4.18 and
 2.1.18, during my tests, seems to default to 256 bits
-[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) for
+AES for
 encryption, but that has not always been the case. The chosen
 encryption algorithm actually depends on the recipient's key
 preferences, which may vary wildly: older keys and version may use

answers from dkg
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 243163f..499faf1 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -263,14 +263,20 @@ Other notable password managers
 -------------------------------
 
 Another alternative password manager, briefly mentioned in the
-previous article, is the [assword](https://finestructure.net/assword/)
-password manager that, despite its questionable name, is also
-interesting. Its main advantage over `pass` is that it uses a single
-encrypted JSON file for storage, and therefore doesn't leak the name
-of the entries by default. In addition to copy/paste, assword also
-supports automatically entering passphrases in fields with the
+previous article, is the minimalistic
+[assword](https://finestructure.net/assword/) password manager that,
+despite its questionable name, is also interesting. Its main advantage
+over `pass` is that it uses a single encrypted JSON file for storage,
+and therefore doesn't leak the name of the entries by default. In
+addition to copy/paste, assword also supports automatically entering
+passphrases in fields with the
 [xdo](https://www.semicomplete.com/projects/xdotool) library. Like
-`pass`, it also uses GPG to encrypt passphrases.
+`pass`, it also uses GPG to encrypt passphrases. According to dkg, the
+main issue with assword is "interaction between generated passwords
+and insane password policies", giving the example of the Time-Warner
+Cable registration form that requires, among other things, "letters
+and numbers, between 8 and 16 characters and not repeat the same
+characters 3 times in a row".
 
 Another well-known password manager is the commercial
 [LastPass](https://en.wikipedia.org/wiki/Lastpass) service which

final review with dkg, asked him for comments
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index f415d98..243163f 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -10,12 +10,12 @@ professionals, particularly system administrators that have to manage
 a lot of different machines. But it also affects regular users who
 still use a large number of passwords in their daily lives, from their
 online bank credentials to their favorite social networking
-site. Scientists
-[generally agree](https://www.scientificamerican.com/article/what-is-the-memory-capacity/)
-that the human memory is phenomenal, yet it can be hard for users to
-remember a set of abstract characters. Humans, in short, are proving
-to be bad at generating high entropy and unique passwords that they
-can remember.
+site. Despite the
+[remarkable memory capacity of the human brain](https://www.scientificamerican.com/article/what-is-the-memory-capacity/),
+humans are actually terrible at recalling even short sets of arbitrary
+characters with the precision needed to use passwords. Humans, in
+short, are proving to be bad at generating high entropy and unique
+passwords that they can remember.
 
 Therefore humans [reuse passwords](https://xkcd.com/792/), make them
 trivial or guessable, write them down on little paper notes and
@@ -60,7 +60,7 @@ Keepass: the popular alternative
 
 The most commonly used password manager design pattern is to store
 passwords in a file that is encrypted and password-protected. The most
-popular free software password manager of the kind is probably
+popular free software password manager of this kind is probably
 KeePass.
 
 An important feature of KeePass is the ability to auto-type passwords
@@ -267,18 +267,10 @@ previous article, is the [assword](https://finestructure.net/assword/)
 password manager that, despite its questionable name, is also
 interesting. Its main advantage over `pass` is that it uses a single
 encrypted JSON file for storage, and therefore doesn't leak the name
-of the entries by default. It also supports automatically entering
-passphrases in fields with the
-[xdotool](https://www.semicomplete.com/projects/xdotool) library. It
-also uses GPG to encrypt passphrases. At this point, it's still a bit
-too early in the development for wider adoption, as it's missing
-features like git integration. It also lacks an easy way to show the
-password in cleartext easily (you can set the `ASSWORD_DUMP_PASSWORDS`
-environment and dump the JSON entry, but that is not "easy"), which is
-still, unfortunately, necessary in certain circumstances. I am sure
-that the assword authors will defend this decision as an
-anti-foot-shooting device, but I have often found it necessary to
-actually examine the password with my own eyes.
+of the entries by default. In addition to copy/paste, assword also
+supports automatically entering passphrases in fields with the
+[xdo](https://www.semicomplete.com/projects/xdotool) library. Like
+`pass`, it also uses GPG to encrypt passphrases.
 
 Another well-known password manager is the commercial
 [LastPass](https://en.wikipedia.org/wiki/Lastpass) service which
@@ -297,22 +289,22 @@ surface that is not present in regular password managers. A
 [2014 study by University of California researchers](https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/li_zhiwei)
 showed that, out of 5 password managers studied, every one of them was
 vulnerable to at least one of the vulnerabilities studied. LastPass
-was, in particular, vulnerable to a "bookmarklet" and a CSRF
-(Cross-Site Request Forgery) attack.
+was, in particular, vulnerable to a CSRF (Cross-Site Request Forgery)
+attack that allows an attacker to bypass account authentication and
+access the encrypted database.
 
 Issues with password managers
 -----------------------------
 
-Most of the password managers face the problematic issue of access
-revocation when used with multiple users. When you share a password
-database within a team, how do you remove access to a member of the
-team? While you can, for example, re-encrypt a pass database with new
-keys (thereby removing or adding certain accesses) or you can change
-the password on a KeePass database, an hostile party could have always
-made a backup of the database before the revocation. Indeed, in the
-case of `pass`, older entries are even still in the git history... So
-access revocation, in shared password managers, actually means going
-through every password and changing it online.
+When you share a password database within a team, how do you remove
+access to a member of the team? While you can, for example, re-encrypt
+a pass database with new keys (thereby removing or adding certain
+accesses) or you can change the password on a KeePass database, an
+hostile party could have always made a backup of the database before
+the revocation. Indeed, in the case of `pass`, older entries are 
+still in the git history... So access revocation is a problematic
+issue found in all shared password managers, as it may actually mean
+going through every password and changing it online.
 
 This fundamental problem with shared secrets can be better addressed
 with a tool like [Vaultproject.io](https://www.vaultproject.io/) or
@@ -321,8 +313,12 @@ with easy ways to store dynamic tokens like API keys and service
 passwords and share them not only with other humans, but also make
 them accessible to machines. The general idea of those projects is to
 store secrets in a central server and send them directly to relevant
-services without human intervention. If you are looking at password
-management for teams, this may be worth a look.
+services without human intervention. This way, passwords are not
+actually shared anymore, which is similar, in spirit, to the approach
+taken by centralized authentication systems like
+[Kerberos](https://en.wikipedia.org/wiki/Kerberos_(protocol)). If you
+are looking at password management for teams, those projects may be
+worth a look.
 
 Furthermore, some password managers that support auto-typing were
 found to be vulnerable to HTML injection attacks: if some third-party
@@ -344,18 +340,26 @@ your phone to be that trusted device, yet a phone can be lost or
 stolen more easily than a traditionnal workstation or even a
 laptop. And while KeePass has Android and iOS ports, those do not
 resolve the question of how to share the password storage among those
-devices or how to backup those devices. To resolve those issues, people
-are naturally migrating their storage to third party storage servers
-out of their control ("the cloud"). This breaks a fundamental
-assumption in password managers, as the encrypted database can now
-possibly be attacked online. Therefore certain password managers are
-specifically designed for the cloud, like LastPass or web browser
-profile synchronization features, without necessarily addressing the
-inherent issues with cloud storage.
-
-Another approach to resolve those issues are the "stateless" or
-"deterministic" password managers that I generally refer to as
-"password hashers". Those could possibly replace password managers as
-users switch from generic computing platforms to cloud-based
-infrastructure. We will cover password hashers and the major security
-challenges they pose in a future article.
+devices or how to backup those devices.
+
+Password managers are fundamentally file-based, and the "file" concept
+seems to be quickly disappearing, faster than we technologists
+sometimes like to admit. Looking at some relatives' use of computers,
+I notice it is less about "files" than images, videos, recipes and
+various abstract objects that are stored in the "cloud". They do not
+use local storage so much anymore. In that environment, password
+managers lose their primary advantage, which is a local, somewhat
+offline file storage that is not directly accessible to attackerss.
+Therefore certain password managers are specifically designed for the
+cloud, like LastPass or web browser profile synchronization features,
+without necessarily addressing the inherent issues with cloud storage
+and opening up huge privacy and security issues that we absolutely
+need to address.
+
+This is where the "password hasher" design comes in. Also known as
+"stateless" or "deterministic" password managers, password hashers are
+emerging as a convenient solution that could possibly replace
+traditionnal password managers as users switch from generic computing
+platforms to cloud-based infrastructure. We will cover password
+hashers and the major security challenges they pose in a future
+article.

thorough review after dkg's feedback
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index c3d539e..f415d98 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -1,22 +1,25 @@
 A review of password managers
 -----------------------------
 
-While our dependency on password for authentication has often been
-decried as a serious security flaw that we should get rid of, the
-current reality is that we do use a plethora of passwords in our
-daily lives on the internet. This problem is especially acute for
-technology professionals, particularly system administrators that have
-to manage a lot of different machines. But it also
-affects regular users who still use a large number of passwords in
-their daily lives, from their online bank credentials to their
-favorite social networking site. Experiments have shown that the human
-memory is phenomenal, yet it can be hard for users to remember a set
-of abstract characters. Humans, in short, are proving to be bad at
-generating high entropy and unique passwords that they can remember.
+As we discussed in the
+[previous article](https://lwn.net/Articles/713806/), passwords are
+terrible and we'd prefer to get rid of them. But the current reality
+is that we do use a plethora of passwords in our daily lives on the
+internet. This problem is especially acute for technology
+professionals, particularly system administrators that have to manage
+a lot of different machines. But it also affects regular users who
+still use a large number of passwords in their daily lives, from their
+online bank credentials to their favorite social networking
+site. Scientists
+[generally agree](https://www.scientificamerican.com/article/what-is-the-memory-capacity/)
+that the human memory is phenomenal, yet it can be hard for users to
+remember a set of abstract characters. Humans, in short, are proving
+to be bad at generating high entropy and unique passwords that they
+can remember.
 
 Therefore humans [reuse passwords](https://xkcd.com/792/), make them
 trivial or guessable, write them down on little paper notes and
-stick it on their screens or just reset them by email every
+stick them on their screens or just reset them by email every
 time. Our memory is undeniably failing us and we need help.
 
 When giving security training, I often recommend people use three
@@ -42,28 +45,27 @@ my recommendation is generally:
  1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
  2. use a real password manager for the rest
 
-This begs the question of which password manager to use.  There is a
-large variety of password managers out there. At my previous job, we
-have inventoried about
-[40 different password managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
-in the last 8 years, in different stages of development and quality,
-even when limiting ourselves to free software projects. Other sites
-list
-[43 alternatives to the popular Keepass](http://alternativeto.net/software/keepass/?license=opensource)
-password manager. So obviously, this review will not be exhaustive,
-but instead focus on a smaller set of the most well known alternative
-that may be interesting to our readers.
+But there is a large variety of password managers out there, so which
+one should we be using? At my previous job, we have inventoried about
+[40 different free software password managers][] in the last 8 years,
+in different stages of development and quality. So obviously, this
+review will not be exhaustive, but instead focus on a smaller set of
+the most well known alternative that may be interesting to our
+readers.
+
+[40 different free software password managers]: https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison
 
 Keepass: the popular alternative
 --------------------------------
 
-The most commonly used password manager design pattern may well be the
-one used by [KeePass](http://keepass.info/), which is a password
-manager encrypts passwords in a single, password-protected database.
+The most commonly used password manager design pattern is to store
+passwords in a file that is encrypted and password-protected. The most
+popular free software password manager of the kind is probably
+KeePass.
 
-One key feature of KeePass is the ability to auto-type passwords
+An important feature of KeePass is the ability to auto-type passwords
 in forms, most notably in web browsers. This feature makes KeePass really
-easy to use, especially considering they also support global
+easy to use, especially considering it also supports global
 keybindings to access passwords. KeePass databases are also designed
 for simultaneous access by multiple users for example using a shared
 network drive. 
@@ -101,7 +103,7 @@ since the last 2.0.3 release in september.
 KeePass and derivatives do not support multi-tiered access in a single
 database. To restrict access between teams, operators will need to use
 separate databases for each team, with each team using a different
-share secret.
+shared secret.
 
 Pass: the standard password manager?
 ------------------------------------
@@ -126,13 +128,20 @@ password for your LWN account and copy it to the clipboard:
 The main issue with `pass` is that it doesn't encrypt the *name* of
 those entries: if someone would compromise my machine, they could
 easily see which sites I have access to simply by listing the password
-stored in `~/.password-store`.
+stored in `~/.password-store`. This is a deliberate design decision by
+upstream, as
+[stated](https://lists.zx2c4.com/pipermail/password-store/2014-June/001001.html)
+by a mailing list participant, Allan Odgaard: "Using a single file per
+item has the advantage of shell completion, using version control,
+[manipulate files directly], etc." As Odgaard then says, "there are
+already alternative password managers that
+[use a single (encrypted) database]".
 
 Also, sharing a database for multi-user support will require some sort
 of file-sharing mechanism. Given the integrated git support, this will
 likely involve setting up a private git repository for your team,
 something which may not be accessible to the average Linux
-user. Nothing keeps you, however, to share the `~/.password-store`
+user. Nothing keeps you, however, from sharing the `~/.password-store`
 directory through another file sharing mechanism like (say)
 [Syncthing](https://syncthing.net/) or [Dropbox][].
 
@@ -145,7 +154,7 @@ with:
 
     alias work-pass="PASSWORD_STORE_DIR=~/work-passwords pass"
 
-Group support comes from a clever use of GPG multiple-recipient
+Group support comes from a clever use of GnuPG multiple-recipient
 encryption support. You simply have to specify multiple OpenPGP
 identities when initializing the repository, which also works in
 subdirectories:
@@ -158,11 +167,15 @@ subdirectories:
      create mode 100644 Ateam/.gpg-id
 
 The above will configure `pass` to encrypt the passwords in the
-`Ateam` directory to "me" and "joelle".
-
-A key issue of `pass` is that it depends on GnuPG to do the right
-thing when encrypting files. GnuPG 1.4.18 and 2.1.18, during my tests,
-seems to default to 256 bits
+`Ateam` directory to `me@example.com` and `joelle@example.com`. `pass`
+depends on GnuPG to do the right thing when encrypting files and how
+those identities are treated is entirely delegated to GnuPG's default
+configuration. This could lead to problems if arbitrary keys can be
+injected in your keyring which could confuse GnuPG. I would therefore
+recommend using full key fingerprints instead of user identifiers.
+
+Regarding the actual encryption algorithms used, GnuPG 1.4.18 and
+2.1.18, during my tests, seems to default to 256 bits
 [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) for
 encryption, but that has not always been the case. The chosen
 encryption algorithm actually depends on the recipient's key
@@ -214,34 +227,49 @@ that was
 
 In Firefox, there's an optional, profile-specific master password that
 unlocks all passwords. In this case the issue is that browsers are
-generally always opened and the vault is always unlocked... This is a
-typical convenience-security trade-off: either users need to
-constantly input their master passwords to login or they don't, and
-the passwords are available in the clear. In this case, Chromium's
-approach of actually asking users to unlock their vault seems
-preferable, even though they actually
+generally always opened and the vault is always unlocked...  And this
+is for users that actually *do* pick a master passwords; users are
+often are often completely unaware that they should set a master
+password.
+
+The unlocking mechanism is a typical convenience-security trade-off:
+either users need to constantly input their master passwords to login
+or they don't, and the passwords are available in the clear. In this
+case, Chromium's approach of actually asking users to unlock their
+vault seems preferable, even though they actually
 [refused to implement the feature for years](https://bugs.chromium.org/p/chromium/issues/detail?id=1397).
 
-Overall, I would recommend against using browser-based password
-managers. Even if they are not used for critical sites, you will end
-up with hundreds of such passwords that are vulnerable while the
-browser is running (in the case of Firefox) or at the whim of Google
-(in the case of Chromium). Furthermore, because they lack a proper
+Overall, I would recommend against using a browser-based password
+manager. Even if it is not used for critical sites, you will end up
+with hundreds of such passwords that are vulnerable while the browser
+is running (in the case of Firefox) or at the whim of Google (in the
+case of Chromium). Furthermore, the "autofill" feature that is
+often coupled with browser-based password managers is often vulnerable
+to serious attacks which we discuss below.
+
+Finally, because browser-based managers generally lack a proper
 password generator, users may fail to use
 [properly generated passwords](https://lwn.net/Articles/713806/) which
-can then be easily broken.
+can then be easily broken. A password generator may actually be
+implemented soon in Firefox, according to this
+[feature request](https://bugzilla.mozilla.org/show_bug.cgi?id=376674)
+opened in 2007, and there *is* a
+[password generator in Chrome](https://www.chromium.org/developers/design-documents/password-generation),
+but it is disabled by default and hidden in the mysterious
+[chrome://flags](http://blogs.adobe.com/cantrell/archives/2012/07/all-about-chrome-flags.html)
+secret URL.
 
 Other notable password managers
 -------------------------------
 

(fichier de différences tronqué)
add two recipes
diff --git a/recette.mdwn b/recette.mdwn
index af15014..0ad5ecf 100644
--- a/recette.mdwn
+++ b/recette.mdwn
@@ -19,3 +19,6 @@ Autres recettes
 * Ricardo:
   * [Pain naan](https://www.ricardocuisine.com/recettes/153-pain-naan)
   * [Mango lassi](https://www.ricardocuisine.com/recettes/6705-lassi-a-la-mangue#nutritionFactsItem)
+  * [Pâte à choux](https://www.ricardocuisine.com/recettes/4586-pate-a-choux-)
+* Autres:
+  * [Pad Thai](http://www.thaitable.com/thai/recipe/pad-thai)

add two recipes
diff --git a/recette.mdwn b/recette.mdwn
index af15014..0ad5ecf 100644
--- a/recette.mdwn
+++ b/recette.mdwn
@@ -19,3 +19,6 @@ Autres recettes
 * Ricardo:
   * [Pain naan](https://www.ricardocuisine.com/recettes/153-pain-naan)
   * [Mango lassi](https://www.ricardocuisine.com/recettes/6705-lassi-a-la-mangue#nutritionFactsItem)
+  * [Pâte à choux](https://www.ricardocuisine.com/recettes/4586-pate-a-choux-)
+* Autres:
+  * [Pad Thai](http://www.thaitable.com/thai/recipe/pad-thai)

add bits about gnupg algos
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index ad62a51..c3d539e 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -108,7 +108,7 @@ Pass: the standard password manager?
 
 I am currently using [password-store](https://www.passwordstore.org/),
 or `pass`, as a password manager. It aims to be "the standard unix
-password manager". `pass` is a gpg-based password manager that
+password manager". `pass` is a GnuPG-based password manager that
 features a surprising number of features given its small size:
 
 * copy-paste support
@@ -160,6 +160,26 @@ subdirectories:
 The above will configure `pass` to encrypt the passwords in the
 `Ateam` directory to "me" and "joelle".
 
+A key issue of `pass` is that it depends on GnuPG to do the right
+thing when encrypting files. GnuPG 1.4.18 and 2.1.18, during my tests,
+seems to default to 256 bits
+[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) for
+encryption, but that has not always been the case. The chosen
+encryption algorithm actually depends on the recipient's key
+preferences, which may vary wildly: older keys and version may use
+anything from 128 bits AES to
+[CAST5](https://en.wikipedia.org/wiki/CAST-128) or
+[Triple DES](https://en.wikipedia.org/wiki/Triple_DES). To figure out
+which algorithm GnuPG chose, you may want to try this pipeline:
+
+    $ echo test | gpg -e -r you@example.com | gpg -d -v
+    [...]
+    gpg: encrypted with 2048-bit RSA key, ID XXXXXXX, created XXXXX
+          "You Person You <you@example.com>"
+    gpg: AES256 encrypted data
+    gpg: original file name=''
+    test
+
 As you can see, `pass` is primarily a commandline application which
 makes it less accessible to regular users. The community has produced
 a different graphical interfaces that are either using `pass` directly

final review to get a first draft
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 5bce826..ad62a51 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -3,41 +3,44 @@ A review of password managers
 
 While our dependency on password for authentication has often been
 decried as a serious security flaw that we should get rid of, the
-current reality is that we have to use a plethora of passwords in our
+current reality is that we do use a plethora of passwords in our
 daily lives on the internet. This problem is especially acute for
-technology professionals and in particular sysadmins. But it also
-affects regular users which have to use a large number of passwords in
+technology professionals, particularly system administrators that have
+to manage a lot of different machines. But it also
+affects regular users who still use a large number of passwords in
 their daily lives, from their online bank credentials to their
 favorite social networking site. Experiments have shown that the human
 memory is phenomenal, yet it can be hard for users to remember a set
 of abstract characters. Humans, in short, are proving to be bad at
 generating high entropy and unique passwords that they can remember.
 
-Therefore humans [reuse passwords](https://xkcd.com/792/), choose
-trivial or guessable ones, write them down on little post-its and
+Therefore humans [reuse passwords](https://xkcd.com/792/), make them
+trivial or guessable, write them down on little paper notes and
 stick it on their screens or just reset them by email every
 time. Our memory is undeniably failing us and we need help.
 
-For this purpose, I recommend people use three different strategies
-for passwords:
+When giving security training, I often recommend people use three
+different strategies for passwords:
 
- 1. use a password hasher in the browser, or use the "master key
-    feature" of browsers to store passwords for most (unimportant)
-    websites
+ 1. use a "stateless password manager" in the browser, or use the
+    "master key feature" of browsers to store passwords for most
+    (unimportant) websites
  2. use a password manager for more critical passwords (online bank
     account, main email account, etc)
  3. remember a small set of critical passwords (bank card PIN,
-    password manager and hasher passwords)
+    password manager passwords)
 
-Unfortunately, a recent review of the code of the password hasher I
-was using has made me change my mind about that key recommendation,
-which I will explain in a later article. Furthermore, Chromium doesn't
-support using a master key, so that option is not portable. Therefore,
-for users that can afford having a trusted computer regularly
-accessible, my recommendation is generally:
+Unfortunately, a recent code review of the stateless password manager
+I was using
+([Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd/related?hl=en))
+made me change my mind about that recommendation, which I will explain
+in a later article. Furthermore, browser-based password managers have
+their own set of issues covered later in this article. Therefore, for
+users that can afford having a trusted computer regularly accessible,
+my recommendation is generally:
 
  1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
- 2. use a password manager for the rest
+ 2. use a real password manager for the rest
 
 This begs the question of which password manager to use.  There is a
 large variety of password managers out there. At my previous job, we
@@ -169,22 +172,67 @@ user-friendly. QtPass doesn't actually depend on `pass` and can use
 `gpg` directly to interact with the `pass` database and is available
 for Linux, BSD, OS X and Windows.
 
-Other alternatives
-------------------
-
-One alternative, quickly mentionned in the previous article, is the
-[assword](https://finestructure.net/assword/) password manager that,
-despite its name, is also interesting. Its main advantage over pass
-is that it uses a single encrypted JSON file for storage, and
-therefore doesn't leak the name of the entries by default. It also
-supports automatically entering passphrases in fields with the
-[xdotool](https://www.semicomplete.com/projects/xdotool)
-program. It uses GPG to encrypt passphrases but it's still a bit
+Browser password managers
+-------------------------
+
+Most users are probably already using a password manager through their
+web browser "remember password" functionality. For example, Chromium
+will ask you to remember passwords and encrypt them with your
+operating system's facilities. In Windows this encrypts the passwords
+with your login password and in GNOME this will store the passwords in
+the gnome-keyring storage. If you synchronize your Chromium settings
+with your Google account, Chromium will store those passwords in
+Google's server, encrypted with a key that is...
+[stored in the Google Account itself](https://productforums.google.com/forum/#!topic/chrome/p0vglq4ZG-8)!
+So your passwords are then only as safe as your Google account. Note
+that this was
+[previously discussed here in 2010](https://lwn.net/Articles/388309/)
+although back then Chromium didn't synchronize with the Google cloud
+or encryption with the system-level keyrings back then, a facility
+that was
+[added only in 2013](https://arstechnica.com/information-technology/2013/11/google-finally-hides-passwords-from-snoopers-in-new-builds-of-chromium/).
+
+In Firefox, there's an optional, profile-specific master password that
+unlocks all passwords. In this case the issue is that browsers are
+generally always opened and the vault is always unlocked... This is a
+typical convenience-security trade-off: either users need to
+constantly input their master passwords to login or they don't, and
+the passwords are available in the clear. In this case, Chromium's
+approach of actually asking users to unlock their vault seems
+preferable, even though they actually
+[refused to implement the feature for years](https://bugs.chromium.org/p/chromium/issues/detail?id=1397).
+
+Overall, I would recommend against using browser-based password
+managers. Even if they are not used for critical sites, you will end
+up with hundreds of such passwords that are vulnerable while the
+browser is running (in the case of Firefox) or at the whim of Google
+(in the case of Chromium). Furthermore, because they lack a proper
+password generator, users may fail to use
+[properly generated passwords](https://lwn.net/Articles/713806/) which
+can then be easily broken.
+
+Other notable password managers
+-------------------------------
+
+Another alternative password manager, quickly mentioned in the
+previous article, is the [assword](https://finestructure.net/assword/)
+password manager that, despite its questionable name, is also
+interesting. Its main advantage over `pass` is that it uses a single
+encrypted JSON file for storage, and therefore doesn't leak the name
+of the entries by default. It also supports automatically entering
+passphrases in fields with the
+[xdotool](https://www.semicomplete.com/projects/xdotool) program. It
+also uses GPG to encrypt passphrases. At this point, it's still a bit
 too early in the development for wider adoption, as it's missing
-features like git integration or showing the password in cleartext
-easily.
-
-Another is the commercial
+features like git integration. It also lacks an easy way to show the
+password in cleartext easily (you can set the `ASSWORD_DUMP_PASSWORDS`
+environment and dump the JSON entry, but that is not "easy"), which is
+still, unfortunately, necessary in certain circumstances. I am sure
+that the assword authors will defend this decision as an
+anti-foot-shooting device, but I have often found it necessary to
+actually examine the password with my own eyes.
+
+Another well-known password manager is the commercial
 [LastPass](https://en.wikipedia.org/wiki/Lastpass) service who
 [released](https://blog.lastpass.com/2014/10/open-sourced-lastpass-command-line-application-now-available.html/)
 a free software commandline client called
@@ -240,13 +288,14 @@ Future of password managers?
 ----------------------------
 
 All the solutions discussed here assume you have a computer you
-regularly have access to, which is a usage pattern that is
-disappearing with a vast majority of the population. While KeePass has
+regularly have access to, which is a usage pattern that seems to be
+disappearing with a majority of the population. While KeePass has
 Android and iOS ports, it still poses the question of how to share the
 files. People are therefore using more and more "cloud-based" password
-managers like [LastPass](https://en.wikipedia.org/wiki/LastPass), or
-bookmarklets and other gizmos I have called password hashers. Those
-will possibly replace password managers as users switch from generic
-computing platforms to cloud-based infrastructure. We will cover
-password hashers and the major security challenges they pose in a
-future article.
+managers like LastPass or Chromium's synchronization feature. Another
+solution are bookmarklets and other "stateless" or "deterministic"
+password managers that I generally refer to as "password
+hashers". Those will possibly replace password managers as users
+switch from generic computing platforms to cloud-based
+infrastructure. We will cover password hashers and the major security
+challenges they pose in a future article.

fix some lastpass references
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index a38cb4c..5bce826 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -184,16 +184,26 @@ too early in the development for wider adoption, as it's missing
 features like git integration or showing the password in cleartext
 easily.
 
-Another is the commercial [LastPass]() service who
+Another is the commercial
+[LastPass](https://en.wikipedia.org/wiki/Lastpass) service who
 [released](https://blog.lastpass.com/2014/10/open-sourced-lastpass-command-line-application-now-available.html/)
 a free software commandline client called
 [lastpass-cli](https://github.com/lastpass/lastpass-cli) about three
-years ago. Unfortunately, the server software of the lastpass.com
-service is still proprietary, and given they have had at least
+years ago. Unfortunately, the server software of the
+[lastpass.com](https://lastpass.com/) service is still proprietary,
+and given they have had at least
 [two serious security breaches](https://en.wikipedia.org/wiki/LastPass#Security_issues)
 since that release, one could legitimetly question whether this is a
 viable solution for storing important secrets.
 
+In general, web-based password managers have serious usability issues
+and expose a whole new attack surface that is not present in regular
+password managers. A
+[2014 study by University of California researchers](https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/li_zhiwei)
+showed that, out of 5 password managers studied, every one of them was
+vulnerable to at least one of the vulnerabilities studied. LastPass
+was, in particular, vulnerable to a "bookmarklet" and a CSRF (Cross-Site
+Request Forgery) attack.
 
 Issues with password managers
 -----------------------------
@@ -216,14 +226,15 @@ passwords and share them not only with other humans, but also make
 them accessible. If, however, you are looking at password management
 for teams, this may be worth a look.
 
-Furthermore, some password managers like LastPass that support
-auto-typing were found to be vulnerable to HTML injection attacks: if
-some third-party ad or content is able to successfully hijack the
-parent DOM content, they masquerade as a form that could fool
-auto-typing software as demonstrated by this
+Furthermore, some password managers that support auto-typing were
+found to be vulnerable to HTML injection attacks: if some third-party
+ad or content is able to successfully hijack the parent DOM content,
+they masquerade as a form that could fool auto-typing software as
+demonstrated by this
 [paper](http://crypto.stanford.edu/~dabo/pubs/abstracts/pwdmgrBrowser.html)
-[submitted at USENIX 2014](https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver). KeePass
-was, fortunately, not vulnerable according to the security researchers.
+[submitted at USENIX 2014](https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver). Fortunately,
+KeePass was not vulnerable according to the security researchers, but
+LastPass was, again, vulnerable.
 
 Future of password managers?
 ----------------------------

add new bug with scdaemon
diff --git a/blog/2015-12-14-yubikey-howto.mdwn b/blog/2015-12-14-yubikey-howto.mdwn
index a33c8f6..6e0722d 100644
--- a/blog/2015-12-14-yubikey-howto.mdwn
+++ b/blog/2015-12-14-yubikey-howto.mdwn
@@ -184,6 +184,23 @@ gpg-agent to be able to talk with the key:
  [Yubikey importing keys howto]: https://developers.yubico.com/PGP/Importing_keys.html
  [this howto]: https://blog.night-shade.org.uk/2015/04/ssh-support-in-gpg-agent-on-ubunt/
 
+[[!important """
+Note that you do not need `pcscd` in later versions of the GnuPG
+suite. In fact, it can even cause problems because of a bug in the
+2.1.18-4 version of scdaemon that fails to fallback to PC/SC mode when
+the CCID mode fails because `pcscd` is installed. If that sounds
+completely alien to you, don't worry, it was the same for me. Just
+make sure to uninstall `pcscd` and that have the following line in
+`/lib/udev/rules.d/60-scdaemon.rules` - if not, you can add it to a
+temporary file in `/etc/udev/rules.d/yubikey-neo-otp-ccid.rules`:
+
+    ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0111", MODE="664", GROUP="plugdev"
+
+See [[!debbug 854005]] and [[!debbug 854616]] for all the gory
+details. Those bugs were found while Debian 9.0 (`stretch`) was in
+testing, so they may have already been fixed.
+"""]]
+
 Well that failed. At this point, touching the key types a bunch of
 seemingly random characters wherever my cursor is sitting - fun but
 totally useless still. That was because I failed to reconnect the key:
@@ -437,6 +454,7 @@ it impossible to read the card at all. The symptom is this:
     gpg: OpenPGP card not available: No such device
 
 The workaround documented there is to add `disable-ccid` to
-`~/.gnupg/scdaemon.conf`.
+`~/.gnupg/scdaemon.conf`. The proper fix is to uninstall `pcscd` and
+make sure you have the appropriate udev rule, as mentioned earlier.
 
 [[!tag debian-planet geek software debian hacking security crypto]]

chrome + passowrds is a thing of course
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index f7dc881..030c9a3 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -381,3 +381,7 @@ extracted notes, from https://news.ycombinator.com/item?id=12890997:
 
 
 https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/li_zhiwei
+
+chrome can remember passwords as well:
+
+https://support.google.com/chrome/answer/95606?visit_id=0-636221855308687727-338932828&p=settings_password&rd=1

write conclusion and some minor changes
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 4ed7c9f..a38cb4c 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -22,7 +22,7 @@ For this purpose, I recommend people use three different strategies
 for passwords:
 
  1. use a password hasher in the browser, or use the "master key
-    feature" of Firefox to store passwords for most (unimportant)
+    feature" of browsers to store passwords for most (unimportant)
     websites
  2. use a password manager for more critical passwords (online bank
     account, main email account, etc)
@@ -33,14 +33,15 @@ Unfortunately, a recent review of the code of the password hasher I
 was using has made me change my mind about that key recommendation,
 which I will explain in a later article. Furthermore, Chromium doesn't
 support using a master key, so that option is not portable. Therefore,
-I have reduced my recommendation to:
+for users that can afford having a trusted computer regularly
+accessible, my recommendation is generally:
 
  1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
  2. use a password manager for the rest
 
-This begs the question of which password manager one should be using?
-There is a large variety of password managers out there. At my
-previous job, we have inventoried about
+This begs the question of which password manager to use.  There is a
+large variety of password managers out there. At my previous job, we
+have inventoried about
 [40 different password managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
 in the last 8 years, in different stages of development and quality,
 even when limiting ourselves to free software projects. Other sites
@@ -53,9 +54,9 @@ that may be interesting to our readers.
 Keepass: the popular alternative
 --------------------------------
 
-The most commonly used password manager design may well be the one
-used by [KeePass](http://keepass.info/), which is a password manager
-encrypts passwords in a single, password-protected database.
+The most commonly used password manager design pattern may well be the
+one used by [KeePass](http://keepass.info/), which is a password
+manager encrypts passwords in a single, password-protected database.
 
 One key feature of KeePass is the ability to auto-type passwords
 in forms, most notably in web browsers. This feature makes KeePass really
@@ -224,5 +225,17 @@ auto-typing software as demonstrated by this
 [submitted at USENIX 2014](https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver). KeePass
 was, fortunately, not vulnerable according to the security researchers.
 
-
-Stay tuned for the last article in the series about password hashers.
+Future of password managers?
+----------------------------
+
+All the solutions discussed here assume you have a computer you
+regularly have access to, which is a usage pattern that is
+disappearing with a vast majority of the population. While KeePass has
+Android and iOS ports, it still poses the question of how to share the
+files. People are therefore using more and more "cloud-based" password
+managers like [LastPass](https://en.wikipedia.org/wiki/LastPass), or
+bookmarklets and other gizmos I have called password hashers. Those
+will possibly replace password managers as users switch from generic
+computing platforms to cloud-based infrastructure. We will cover
+password hashers and the major security challenges they pose in a
+future article.

add researcher's paper
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index d5a4cb4..f7dc881 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -378,3 +378,6 @@ extracted notes, from https://news.ycombinator.com/item?id=12890997:
 6. Rotating your passwords regularly, at least for your highly sensitive accounts, is very important. With this approach, you can't change any one of your passwords without changing the whole lot (i.e. changing your master password) which simply isn't practical.
 
 7. They serve the whole thing over the web, which, as has been pointed out many times over the web[1], is a bad idea.
+
+
+https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/li_zhiwei

review article, reshuffle, and expand pass section
diff --git a/blog/password-managers.mdwn b/blog/password-managers.mdwn
index 7807226..4ed7c9f 100644
--- a/blog/password-managers.mdwn
+++ b/blog/password-managers.mdwn
@@ -1,17 +1,5 @@
-This article is the second in the series of three about passwords.
-
- 1. The first article covers passwords, how to generate them and a
-    discussion about entropy.
- 
- 2. The second article covers password managers and evaluates a few
-    common software alternatives and practices.
-
- 3. The third article covers password "hashers", that generate
-    multiple passwords from a single one, and that had become more
-    popular in recent years, while being somewhat controversial.
-
-Password managers and hashers: a review
----------------------------------------
+A review of password managers
+-----------------------------
 
 While our dependency on password for authentication has often been
 decried as a serious security flaw that we should get rid of, the
@@ -30,33 +18,27 @@ trivial or guessable ones, write them down on little post-its and
 stick it on their screens or just reset them by email every
 time. Our memory is undeniably failing us and we need help.
 
-This is generally where security professionals teach users about
-password managers. I often recommend people use three different strategies for
-passwords:
+For this purpose, I recommend people use three different strategies
+for passwords:
 
- 1. use a password hasher
-    in the browser, or use the "master key feature" of Firefox to
-    store passwords for most (unimportant) websites
+ 1. use a password hasher in the browser, or use the "master key
+    feature" of Firefox to store passwords for most (unimportant)
+    websites
  2. use a password manager for more critical passwords (online bank
     account, main email account, etc)
  3. remember a small set of critical passwords (bank card PIN,
     password manager and hasher passwords)
 
-Unfortunately, a recent review of the code and design of password
-hashers has made me change my mind about that key
-recommendation. Furthermore, Chromium doesn't support using a master
-key, so that recommendation is not portable. Therefore, I have reduced
-my recommendation to:
+Unfortunately, a recent review of the code of the password hasher I
+was using has made me change my mind about that key recommendation,
+which I will explain in a later article. Furthermore, Chromium doesn't
+support using a master key, so that option is not portable. Therefore,
+I have reduced my recommendation to:
 
- 1. remember a handful of strong passwords
+ 1. remember a handful of [carefully generated passwords](https://lwn.net/Articles/713806/)
  2. use a password manager for the rest
 
 This begs the question of which password manager one should be using?
-Let's look at a few alternatives.
-
-Pass: the standard password manager?
-------------------------------------
-
 There is a large variety of password managers out there. At my
 previous job, we have inventoried about
 [40 different password managers](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
@@ -68,71 +50,32 @@ password manager. So obviously, this review will not be exhaustive,
 but instead focus on a smaller set of the most well known alternative
 that may be interesting to our readers.
 
-I am currently using [password-store](https://www.passwordstore.org/),
-or `pass`, as a password manager. It aims to be "the standard unix
-password manager". `pass` is a gpg-based password manager that
-features a surprising number of features given its small size:
-copy-paste support, git integration, and multi-user support. The
-commandline interface is simple to use and intuitive. The following,
-will, for example, create a pass repository, a 20 character password
-for your LWN account and copy it to the clipboard:
-
-    pass init
-    pass generate -c lwn 20
-
-The main concern with `pass` is that it doesn't encrypt the *name* of
-those entries: if someone would compromise my machine, they could
-easily see which sites I have access to simply by listing the password
-stored in `~/.password-store`. Also, multi-user support depends on git
-support, which will likely involve setting up a private git repository
-for your team, something which may not be accessible to the average
-Linux user. `pass` is primarily a commandline application which makes
-it less accessible as well, although the community has produced a
-different graphical interfaces that are either using `pass` directly
-or operate on the storage with their own GPG integration. I
-personally use `pass` in combination with
-[rofi](https://davedavenport.github.io/rofi/) to get quick access to
-my passwords, but your usage will probably vary.
-
 Keepass: the popular alternative
 --------------------------------
 
-Taking another approach, the well-known
-[KeePass](http://keepass.info/) password manager encrypts passwords in
-a single, password-protected database. Keepass is a graphical
-interface written in C#, so it uses the Mono framework in Linux. A
-separate project, called [KeePassX](https://www.keepassx.org/) is a
-cleanroom implementation written on C++ and QT. Both support the AES
-and Twofish encryption algorithms, although Keepass recently added
-support for the ChaCha20 cipher. AES key derivation is also used to
-generate the actual encryption key for the database, but the latest
-release of KeePass also added using
-[Argon2](https://en.wikipedia.org/wiki/Argon2) the winner of the July
-2015
-[password hashing competition](https://password-hashing.net/). Both
-programs are more or less equivalent, although the original KeePass
-seem to be more featureful in general.
+The most commonly used password manager design may well be the one
+used by [KeePass](http://keepass.info/), which is a password manager
+encrypts passwords in a single, password-protected database.
 
-One key feature of both programs is the ability to auto-type passwords
-in forms, most notably in web browsers. The makes those tools really
+One key feature of KeePass is the ability to auto-type passwords
+in forms, most notably in web browsers. This feature makes KeePass really
 easy to use, especially considering they also support global
 keybindings to access passwords. KeePass databases are also designed
 for simultaneous access by multiple users for example using a shared
-network drive. One feature missing compared with pass would be the
-possibility of encrypting a different parts of a database to different
-user groups: pass supports the use of `.gpg-id` files that list
-multiple key identifiers that must encrypt the subdirectory. In
-comparison, users would need to share different files with different
-passphrases in order to have different access levels.
-
-In both cases, access revocation is a sensitive issue: while you can
-re-encrypt a pass database with new keys (thereby removing or adding
-certain accesses) or you can change the password on a KeePass
-database, an hostile party could have always made a backup of the
-database before the revocation. Indeed, in the case of `pass`, older
-entries are even still in the git history... So access revocation, in
-shared password managers, actually means going through every password
-and changing it online.
+network drive. 
+
+Keepass is a graphical interface written in C#, so it uses the Mono
+framework in Linux. A separate project, called
+[KeePassX](https://www.keepassx.org/) is a cleanroom implementation
+written on C++ and QT. Both support the AES and Twofish encryption
+algorithms, although Keepass recently added support for the ChaCha20
+cipher. AES key derivation is also used to generate the actual
+encryption key for the database, but the latest release of KeePass
+also added using [Argon2](https://en.wikipedia.org/wiki/Argon2) the
+winner of the July 2015
+[password hashing competition](https://password-hashing.net/). Both
+programs are more or less equivalent, although the original KeePass
+seem to be more featureful in general.
 
 I should finally note that the KeePassX project has recently been
 forked into another project now called
@@ -151,6 +94,80 @@ the original [KeePassX project](https://github.com/keepassx/keepassx)
 now has 79 pending pull requests and only one pull request was merged
 since the last 2.0.3 release in september.
 
+KeePass and derivatives do not support multi-tiered access in a single
+database. To restrict access between teams, operators will need to use
+separate databases for each team, with each team using a different
+share secret.
+
+Pass: the standard password manager?
+------------------------------------
+
+I am currently using [password-store](https://www.passwordstore.org/),
+or `pass`, as a password manager. It aims to be "the standard unix
+password manager". `pass` is a gpg-based password manager that
+features a surprising number of features given its small size:
+
+* copy-paste support
+* git integration
+* multi-user/group support
+* pluggable extensions
+
+The commandline interface is simple to use and intuitive. The
+following, will, for example, create a pass repository, a 20 character
+password for your LWN account and copy it to the clipboard:
+
+    pass init
+    pass generate -c lwn 20
+
+The main issue with `pass` is that it doesn't encrypt the *name* of
+those entries: if someone would compromise my machine, they could
+easily see which sites I have access to simply by listing the password
+stored in `~/.password-store`.
+
+Also, sharing a database for multi-user support will require some sort
+of file-sharing mechanism. Given the integrated git support, this will
+likely involve setting up a private git repository for your team,
+something which may not be accessible to the average Linux
+user. Nothing keeps you, however, to share the `~/.password-store`
+directory through another file sharing mechanism like (say)

(fichier de différences tronqué)
hide unreleased article
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
deleted file mode 100644
index d5a4cb4..0000000
--- a/blog/password-hashers.mdwn
+++ /dev/null
@@ -1,380 +0,0 @@
-This article is the second in the series of three about passwords.
-
- 1. The first article covers passwords, how to generate them and a
-    discussion about entropy.
- 
- 2. The second article covers password managers and evaluates a few
-    common software alternatives and practices.
-
- 3. The third article covers password "hashers", that generate
-    multiple passwords from a single one, and that had become more
-    popular in recent years, while being somewhat controversial.
-
-In previous articles, we have seen how to generate passwords and
-security tokens, and a short review of the password managers available
-on Linux platforms. There is, however, a third way of managing
-passwords other than remembering them or encrypting them in a "vault",
-and that is what I call "password hashing". You may know those as
-"deterministic or stateless password managers" but I find the
-"password manager" denomination to be confusing because it doesn't
-actually store any password.
-
-In this text, I use the word "password" for a random string used to
-unlock things, but "token" to represent a generated random string that
-the user doesn't need to remember. The input of a password hasher is
-a password and the output of a password hasher is a token.
-
-What is a password hasher?
---------------------------
-
-A password hasher is a piece of software that turns a single master
-password into multiple passwords by hashing the master password and a
-unique token (generally the hostname) to create a site-specific
-password. To change the password, the user can modify the unique
-token, for example by appending a number. Certain password managers
-also have different settings to generate passwords of different
-lengths or compositions (symbols or not, etc) to accomodate different
-site-specific password policies.
-
-The biggest advantage of password hashers is obviously that you only
-need to remember a password. But contrary to password managers, you do
-not need to carry a password vault around: there's no "state" (other
-than site-specific settings, which can be easily guessed) to carry
-around. The whole concept of password hashers relies on the concept of
-one-way,
-[cryptographic hash functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function)
-that take an input and generate an a unique fixed size string, from
-which it is impossible to guess the original input.
-
-Password hashers are generally written as a Javascript bookmarklet or
-browser plugin, and have been around for over a decade although people
-are generally aware of their existence.
-
-A short history of password hashers
------------------------------------
-
-Since the concept is actually so old, it may be useful to go over a
-short history of popular or notable password hashers, before we go
-into the specific issues related to the implementation of a password
-hasher.
-
-[Nic Wolff](http://angel.net/~nic/passwd.current.html)
-[claims](https://news.ycombinator.com/item?id=12892655) to be the
-first to have written such a program, all the
-[way back in 2003](http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html). Back
-then the hashing algorithm was MD5, although Wolff has now updated the
-algorithm to use SHA-1 and still maintains his webpage for public
-use. Another ancient but unrelated implementation, is the Standford
-University Applied Cryptography's
-[pwdhash](https://crypto.stanford.edu/PwdHash) software. That
-implementation was
-[published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/)
-and unfortunately, that implementation was not updated and still uses
-MD5 as an hashing algorithm, but at least it uses
-[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)
-to generate tokens. Those implementations are the simplest essence of
-password hashers: the inputs are simply the site URL and a
-password. So the algorithms are, basically, for Wolff's:
-
-    token = base64(SHA1(password + domain))
-
-And for [Standford's PwdHash](https://www.pwdhash.com/hashed-password.js):
-
-    token = base64(HMAC(MD5, password, domain))) # PwdHash
-
-Another unrelated implementation that is still around is
-[supergenpass](https://chriszarate.github.io/supergenpass/) is a
-bookmarklet that was
-[created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
-originally using MD5 as well but now supports SHA512 now although
-still
-[limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
-and still
-[defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
-with
-[not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
-(10). Note that Chris Zarate, the supergenpass author, actually
-credits Nic Wolff as the inspiration for his
-implementation. Supergenpass is still in active development and is
-available for the browser (as a
-[bookmarklet](https://chriszarate.github.io/supergenpass/)) or mobile
-(as an
-[webpage](https://chriszarate.github.io/supergenpass/mobile/)). Supergenpass
-allows you to modify the password length, but also add an extra
-profile password which adds to the secret and generates a personalized
-[identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
-prevent phishing but it also introduces an interesting protection,
-only found later in Password Hasher Plus. So the
-[Supergenpass algorithm](https://github.com/chriszarate/supergenpass-lib/blob/eb9ee92050813d498229bfe0e6ccbcb87124cf90/src/lib/generate.js#L32) looks something like this:
-
-    token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
-
-Anothor popular implementation is the Wiijo password hasher,
-[created around 2006](http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/).
-It was probably the first shipped as a
-[browser extension](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
-which greatly improved the security of the product as users didn't
-have to continually download the software on the fly. Wiijo's
-algorithm also improved on the above algorithms, as it uses HMAC-SHA1
-instead of plain SHA-1 or HMAC-MD5, which makes it harder to recover
-the plaintext. Password hasher allows you to set different password
-policies (use digits, punctuation, mixed case, special characters and
-password length) and saves the site names it uses for future
-reference. It also happens that the Wiijo password hasher, in turn,
-took its inspiration on *different* project,
-[hashapass.com](http://www.hashapass.com/),
-[created in 2006](http://web.archive.org/web/20060702050519/http://www.hashapass.com/)
-and also based on
-HMAC-SHA-1. [Indeed](http://www.hashapass.com/en/cmd.html), hashapass
-"can easily be generated on almost any modern Unix-like system using
-the following command line pattern":
-
-    echo -n parameter \
-    | openssl dgst -sha1 -binary -hmac password \
-    | openssl enc -base64 \
-    | cut -c 1-8
-
-So the
-[algorithm](https://addons.mozilla.org/en-US/firefox/files/browse/140427/file/chrome/content/passhash-common.js#L298)
-here is obviously:
-
-    token = base64(HMAC(SHA1, password, domain + ":" + counter)))
-
-... although in the case of Password Hasher, there is a special
-routine that takes the token and inserts random characters in locations
-determined by the sum of the values of the characters in the token.
-
-Years later, in 2010, Eric Woodruff ported the Wiijo "password hasher"
-to Chrome and called it
-[Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd?hl=en).
-Like the original password hasher, the "plus" version also keeps those
-settings in the extension and uses HMAC-SHA-1 to generate the
-password, as it is designed to be backwards-compatible with the Wiijo
-password hasher. Woodruff did add an one interesting feature: a
-profile-specific secret key that gets mixed in to create the security
-token. Stealing the master password is therefore not enough to
-generate tokens anymore. This solves one security concern with
-Password Hasher: an hostile page could watch your keystrokes and steal
-your master password and use it to derive passwords on other
-sites. Having a profile-specific secret key, not accessible to the
-site's Javascript works around that issue, but one could argue that
-typing the master password directly in the password file, while
-convenient, is probably just a bad idea in retrospect. The final
-algorithm looks something like:
-
-    token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
-
-Honestly, that seems rather strange, but it's what I read from the
-source code, which is available only after decompressing the extension
-nowadays. I would have expected the simplest version:
-
-    token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain))
-
-Password Hasher Plus then takes the token and applies the same
-special character insertion routine as the Password Hasher.
-
-Last year, [Guillaume Vincent](http://guillaumevincent.com/) a french
-self-described "humanist and scuba diving fan" released the
-[lesspass](https://lesspass.com/) extension for Chrome, Firefox and
-Android. Lesspass introduces numerous interesting functionalities. It
-is probably the first to include a
-[commandline version](https://github.com/lesspass/cli). It also
-[uses](https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4) a
-more robust key derivation algorithm
-([PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)) and takes into
-account the username on the site, allowing multi account support. The
-original release (version 1) used only 8192 rounds which is now
-considered too low. In the
-[bug report](https://github.com/lesspass/lesspass/issues/38) it was
-interesting to note that LessPass couldn't do the usual practice of
-running the key derivation for 1 second to determine the number of
-rounds needed as the results need to be deterministic. At first
-glance, the LessPass source code seems
-[clear and easy to read](https://github.com/lesspass/core/blob/master/src/v2.js)
-at first glance which is always a good sign, but of course, the devil

(fichier de différences tronqué)
hide unreleased articles
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
deleted file mode 100644
index d5a4cb4..0000000
--- a/blog/password-hashers.mdwn
+++ /dev/null
@@ -1,380 +0,0 @@
-This article is the second in the series of three about passwords.
-
- 1. The first article covers passwords, how to generate them and a
-    discussion about entropy.
- 
- 2. The second article covers password managers and evaluates a few
-    common software alternatives and practices.
-
- 3. The third article covers password "hashers", that generate
-    multiple passwords from a single one, and that had become more
-    popular in recent years, while being somewhat controversial.
-
-In previous articles, we have seen how to generate passwords and
-security tokens, and a short review of the password managers available
-on Linux platforms. There is, however, a third way of managing
-passwords other than remembering them or encrypting them in a "vault",
-and that is what I call "password hashing". You may know those as
-"deterministic or stateless password managers" but I find the
-"password manager" denomination to be confusing because it doesn't
-actually store any password.
-
-In this text, I use the word "password" for a random string used to
-unlock things, but "token" to represent a generated random string that
-the user doesn't need to remember. The input of a password hasher is
-a password and the output of a password hasher is a token.
-
-What is a password hasher?
---------------------------
-
-A password hasher is a piece of software that turns a single master
-password into multiple passwords by hashing the master password and a
-unique token (generally the hostname) to create a site-specific
-password. To change the password, the user can modify the unique
-token, for example by appending a number. Certain password managers
-also have different settings to generate passwords of different
-lengths or compositions (symbols or not, etc) to accomodate different
-site-specific password policies.
-
-The biggest advantage of password hashers is obviously that you only
-need to remember a password. But contrary to password managers, you do
-not need to carry a password vault around: there's no "state" (other
-than site-specific settings, which can be easily guessed) to carry
-around. The whole concept of password hashers relies on the concept of
-one-way,
-[cryptographic hash functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function)
-that take an input and generate an a unique fixed size string, from
-which it is impossible to guess the original input.
-
-Password hashers are generally written as a Javascript bookmarklet or
-browser plugin, and have been around for over a decade although people
-are generally aware of their existence.
-
-A short history of password hashers
------------------------------------
-
-Since the concept is actually so old, it may be useful to go over a
-short history of popular or notable password hashers, before we go
-into the specific issues related to the implementation of a password
-hasher.
-
-[Nic Wolff](http://angel.net/~nic/passwd.current.html)
-[claims](https://news.ycombinator.com/item?id=12892655) to be the
-first to have written such a program, all the
-[way back in 2003](http://web.archive.org/web/20031209041954/http://angel.net/~nic/passwd.html). Back
-then the hashing algorithm was MD5, although Wolff has now updated the
-algorithm to use SHA-1 and still maintains his webpage for public
-use. Another ancient but unrelated implementation, is the Standford
-University Applied Cryptography's
-[pwdhash](https://crypto.stanford.edu/PwdHash) software. That
-implementation was
-[published in 2004](https://web.archive.org/web/20040507195550/http://crypto.stanford.edu/PwdHash/)
-and unfortunately, that implementation was not updated and still uses
-MD5 as an hashing algorithm, but at least it uses
-[HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)
-to generate tokens. Those implementations are the simplest essence of
-password hashers: the inputs are simply the site URL and a
-password. So the algorithms are, basically, for Wolff's:
-
-    token = base64(SHA1(password + domain))
-
-And for [Standford's PwdHash](https://www.pwdhash.com/hashed-password.js):
-
-    token = base64(HMAC(MD5, password, domain))) # PwdHash
-
-Another unrelated implementation that is still around is
-[supergenpass](https://chriszarate.github.io/supergenpass/) is a
-bookmarklet that was
-[created around 2007](http://web.archive.org/web/20071116095006/http://supergenpass.com/),
-originally using MD5 as well but now supports SHA512 now although
-still
-[limited to 24 characters like MD5](https://github.com/chriszarate/supergenpass/issues/85)
-and still
-[defaults MD5](https://github.com/chriszarate/supergenpass/blob/master/src/mobile/index.html#L66)
-with
-[not enough rounds](https://github.com/chriszarate/supergenpass/issues/82)
-(10). Note that Chris Zarate, the supergenpass author, actually
-credits Nic Wolff as the inspiration for his
-implementation. Supergenpass is still in active development and is
-available for the browser (as a
-[bookmarklet](https://chriszarate.github.io/supergenpass/)) or mobile
-(as an
-[webpage](https://chriszarate.github.io/supergenpass/mobile/)). Supergenpass
-allows you to modify the password length, but also add an extra
-profile password which adds to the secret and generates a personalized
-[identicon](https://en.wikipedia.org/wiki/Identicon) presumably to
-prevent phishing but it also introduces an interesting protection,
-only found later in Password Hasher Plus. So the
-[Supergenpass algorithm](https://github.com/chriszarate/supergenpass-lib/blob/eb9ee92050813d498229bfe0e6ccbcb87124cf90/src/lib/generate.js#L32) looks something like this:
-
-    token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
-
-Anothor popular implementation is the Wiijo password hasher,
-[created around 2006](http://web.archive.org/web/20070804013826/http://wijjo.com/passhash/).
-It was probably the first shipped as a
-[browser extension](https://addons.mozilla.org/en-US/firefox/addon/password-hasher/)
-which greatly improved the security of the product as users didn't
-have to continually download the software on the fly. Wiijo's
-algorithm also improved on the above algorithms, as it uses HMAC-SHA1
-instead of plain SHA-1 or HMAC-MD5, which makes it harder to recover
-the plaintext. Password hasher allows you to set different password
-policies (use digits, punctuation, mixed case, special characters and
-password length) and saves the site names it uses for future
-reference. It also happens that the Wiijo password hasher, in turn,
-took its inspiration on *different* project,
-[hashapass.com](http://www.hashapass.com/),
-[created in 2006](http://web.archive.org/web/20060702050519/http://www.hashapass.com/)
-and also based on
-HMAC-SHA-1. [Indeed](http://www.hashapass.com/en/cmd.html), hashapass
-"can easily be generated on almost any modern Unix-like system using
-the following command line pattern":
-
-    echo -n parameter \
-    | openssl dgst -sha1 -binary -hmac password \
-    | openssl enc -base64 \
-    | cut -c 1-8
-
-So the
-[algorithm](https://addons.mozilla.org/en-US/firefox/files/browse/140427/file/chrome/content/passhash-common.js#L298)
-here is obviously:
-
-    token = base64(HMAC(SHA1, password, domain + ":" + counter)))
-
-... although in the case of Password Hasher, there is a special
-routine that takes the token and inserts random characters in locations
-determined by the sum of the values of the characters in the token.
-
-Years later, in 2010, Eric Woodruff ported the Wiijo "password hasher"
-to Chrome and called it
-[Password Hasher Plus](https://chrome.google.com/webstore/detail/password-hasher-plus-pass/glopbmohkffbnplcjbbbfmmimfhfnhgd?hl=en).
-Like the original password hasher, the "plus" version also keeps those
-settings in the extension and uses HMAC-SHA-1 to generate the
-password, as it is designed to be backwards-compatible with the Wiijo
-password hasher. Woodruff did add an one interesting feature: a
-profile-specific secret key that gets mixed in to create the security
-token. Stealing the master password is therefore not enough to
-generate tokens anymore. This solves one security concern with
-Password Hasher: an hostile page could watch your keystrokes and steal
-your master password and use it to derive passwords on other
-sites. Having a profile-specific secret key, not accessible to the
-site's Javascript works around that issue, but one could argue that
-typing the master password directly in the password file, while
-convenient, is probably just a bad idea in retrospect. The final
-algorithm looks something like:
-
-    token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
-
-Honestly, that seems rather strange, but it's what I read from the
-source code, which is available only after decompressing the extension
-nowadays. I would have expected the simplest version:
-
-    token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain))
-
-Password Hasher Plus then takes the token and applies the same
-special character insertion routine as the Password Hasher.
-
-Last year, [Guillaume Vincent](http://guillaumevincent.com/) a french
-self-described "humanist and scuba diving fan" released the
-[lesspass](https://lesspass.com/) extension for Chrome, Firefox and
-Android. Lesspass introduces numerous interesting functionalities. It
-is probably the first to include a
-[commandline version](https://github.com/lesspass/cli). It also
-[uses](https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4) a
-more robust key derivation algorithm
-([PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)) and takes into
-account the username on the site, allowing multi account support. The
-original release (version 1) used only 8192 rounds which is now
-considered too low. In the
-[bug report](https://github.com/lesspass/lesspass/issues/38) it was
-interesting to note that LessPass couldn't do the usual practice of
-running the key derivation for 1 second to determine the number of
-rounds needed as the results need to be deterministic. At first
-glance, the LessPass source code seems
-[clear and easy to read](https://github.com/lesspass/core/blob/master/src/v2.js)
-at first glance which is always a good sign, but of course, the devil

(fichier de différences tronqué)
yet more soft, switch to slop/maim for screenshots
diff --git a/software/mytasks.desc b/software/mytasks.desc
index 22aeaf7..af189d0 100644
--- a/software/mytasks.desc
+++ b/software/mytasks.desc
@@ -52,6 +52,9 @@ Packages: list
  mercurial
  myrepos
  ncdu
+ nodejs
+ nodejs-legacy
+ npm
  org-mode
  org-mode-doc
  pastebinit
@@ -60,6 +63,9 @@ Packages: list
  python
  python3
  python-jedi
+ python-pytest
+ python-setuptools-scm
+ python-wheel
  python3-jedi
  python3-pip
  python-pip
@@ -69,8 +75,10 @@ Packages: list
  twine
  qemu
  quilt
+ sqlitebrowser
  subversion
  time
+ twine
  vim
  wget
 
@@ -80,10 +88,12 @@ Description: Anarcat's desktop setup
  Shitload of stuff that doesn't fit anywhere else.
 Packages: list
  arandr
+ aspell-fr
  calibre
  chromium
  diceware
  dict
+ electrum
  emacs
  exiftool
  fim
@@ -95,12 +105,13 @@ Packages: list
  hledger
  jmtpfs
  ledger
- ledger
+ ledger-el
  less
  libnotify-bin
  localepurge
  locales
  mlocate
+ maim
  monkeysign
  monkeysphere
  mpd
@@ -115,6 +126,7 @@ Packages: list
  offlineimap
  openntpd
  parcimonie
+ pavucontrol
  pass
  pcscd
  picard
@@ -127,7 +139,7 @@ Packages: list
  rofi
  rxvt-unicode
  scdaemon
- scrot
+ slop
  sxiv
  taffybar
  thunar
@@ -153,6 +165,9 @@ Description: Anarcat's authorship tools (TeX)
  This is mostly TeX-related packages
 Packages: list
  auctex
+ dict
+ libtext-multimarkdown-perl
+ pandoc
  texlive-latex-base
  texlive-latex-recommended
  texlive-latex-extra
@@ -187,6 +202,7 @@ Packages: list
  rsync
  sdparm
  siege
+ sipcalc
  socat
  sshfs
  strace

tiny change from lwn, and fix markup
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 4865aa5..d968f57 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -37,23 +37,23 @@ assert that a good password has the following properties:
 -   memorable: easy to remember for humans
 
 High entropy means that the password should be unpredictable to an
-attacker, for all practical purposes.  It is tempting (and not
-uncommon) to choose a password based on something else that you know,
-but unfortunately those choices are likely to be guessable, no matter
-how "secret" you believe it is. Yes, with enough effort, an attacker
-can figure out your birthday, the name of your first lover, your
-mother's maiden name, where you were last summer, or other
-secrets people think they have.
-
-The only solution here is to use a password randomly generated
-with enough randomness or "entropy" that brute-forcing the password will
-be practically infeasible. Considering that a modern off-the-shelf
-graphics card can guess millions of passwords per second using freely
-available software like [hashcat](https://www.hashcat.net/hashcat/), the
-typical requirement of "8 characters" is not considered enough anymore.
-With proper hardware, a powerful rig can crack such passwords offline
-within about a day. Even though a recent [US National Institute of
-Standards and Technology (NIST)](https://www.nist.gov/) draft still
+attacker, for all practical purposes. It is tempting (and not uncommon)
+to choose a password based on something else that you know, but
+unfortunately those choices are likely to be guessable, no matter how
+"secret" you believe it is. Yes, with enough effort, an attacker can
+figure out your birthday, the name of your first lover, your mother's
+maiden name, where you were last summer, or other secrets people think
+they have.
+
+The only solution here is to use a password randomly generated with
+enough randomness or "entropy" that brute-forcing the password will be
+practically infeasible. Considering that a modern off-the-shelf graphics
+card can guess millions of passwords per second using freely available
+software like [hashcat](https://www.hashcat.net/hashcat/), the typical
+requirement of "8 characters" is not considered enough anymore. With
+proper hardware, a powerful rig can crack such passwords offline within
+about a day. Even though a recent [US National Institute of Standards
+and Technology (NIST)](https://www.nist.gov/) draft still
 [recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-authenticators)
 a minimum of eight characters, we now more often hear recommendations of
 [twelve
@@ -69,16 +69,16 @@ characters also make it harder for humans to communicate passwords
 across voice channels or different cultural backgrounds. In a more
 extreme example, the popular Signal software even resorted to [using
 only digits](https://whispersystems.org/blog/safety-number-updates/) to
-transfer key fingerprints. They outlined that numbers are "easy to
-localize" (as opposed to words, which are language-specific) and
-"visually distinct".
+transfer key fingerprints. They outlined that numbers are "*easy to
+localize*" (as opposed to words, which are language-specific) and
+"*visually distinct*".
 
 But the critical piece is the "memorable" part: it is trivial to
 generate a random string of characters, but those passwords are hard for
 humans to remember. As [xkcd noted](https://xkcd.com/936/),
-"through 20 years of effort, we've successfully trained everyone
+"*through 20 years of effort, we've successfully trained everyone
 to use passwords that are hard for human to remember but easy for
-computers to guess". It explains how a series of words is a
+computers to guess*". It explains how a series of words is a
 better password than a single word with some characters replaced.
 
 Obviously, you should not need to remember all passwords. Indeed, you
@@ -86,11 +86,11 @@ may store some in password managers (which we'll look at in another
 article) or write them down in your wallet. In those cases, what you
 need is not a password, but something I would rather call a "token", or,
 as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
-"high entropy, compact, and transferable string". Certain APIs are
+"*high entropy, compact, and transferable string*". Certain APIs are
 specifically crafted to use tokens. [OAuth](https://oauth.net/), for
 example, generates "access tokens" that are random strings that give
-access to services. But in our discussion, we'll use the term "token" in a broader
-sense.
+access to services. But in our discussion, we'll use the term "token" in
+a broader sense.
 
 Notice how we removed the "memorable" property and added the "compact"
 one: we want to efficiently convert the most entropy into the shortest
@@ -221,17 +221,17 @@ posting](https://groups.google.com/d/msg/sci.crypt/8QYsDMRPw-o/DXBdw38-PfkJ)
 from 1997.
 
 A key feature of xkcdpass and diceware is that you can craft your own
-word list, which can make dictionary-based attacks harder. Indeed,
-with such word-based password generators, the only viable way to crack
-those passwords is to use dictionary attacks, because the password is so
-long that character-based exhaustive searches are not workable, as
-they would take centuries to complete. Changing from the
-default dictionary therefore brings some advantage against attackers.
-This may be yet another "security through obscurity" procedure, however:
-a naive approach may be to use a dictionary localized to your native
-language (for example, in my case, French), but that would deter only an
-attacker that doesn't do basic research about you, so that advantage is
-quickly lost to determined attackers.
+word list, which can make dictionary-based attacks harder. Indeed, with
+such word-based password generators, the only viable way to crack those
+passwords is to use dictionary attacks, because the password is so long
+that character-based exhaustive searches are not workable, since they
+would take centuries to complete. Changing from the default dictionary
+therefore brings some advantage against attackers. This may be yet
+another "security through obscurity" procedure, however: a naive
+approach may be to use a dictionary localized to your native language
+(for example, in my case, French), but that would deter only an attacker
+that doesn't do basic research about you, so that advantage is quickly
+lost to determined attackers.
 
 One should also note that the entropy of the password doesn't depend on
 which word list is chosen, only its length. Furthermore, a larger
@@ -269,8 +269,8 @@ was suggesting the following pipeline to generate the password:
 The above command reads a certain number of bytes from the kernel
 (`head -c $entropy /dev/random`) encodes that using the `base64`
 algorithm and strips out the trailing equal sign and newlines (for large
-passwords). This is what Gillmor described as a "high-entropy compact
-printable/transferable string". The priority, in this case, is to have a
+passwords). This is what Gillmor described as a "*high-entropy compact
+printable/transferable string*". The priority, in this case, is to have a
 token that is as compact as possible with the given entropy, while at
 the same time using a character set that should cause as little trouble
 as possible on sites that restrict the characters you can use. Gillmor
@@ -295,8 +295,8 @@ that this wastes entropy as the use of `tr` discards bits from
 entropy](https://lists.zx2c4.com/pipermail/password-store/2016-December/002554.html)
 when compared to base64. But in the end, the maintainer
 [argued](https://lists.zx2c4.com/pipermail/password-store/2016-December/002559.html)
-that reading "reading from `/dev/urandom` has no [effect] on
-`/proc/sys/kernel/random/entropy_avail` on Linux" and dismissed
+that reading "*reading from `/dev/urandom` has no \[effect\] on
+`/proc/sys/kernel/random/entropy_avail` on Linux*" and dismissed
 the objection.
 
 Another password manager, [KeePass](http://keepass.info/) uses its own

more fixes from LWN
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 0cb96b0..4865aa5 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -178,15 +178,14 @@ computer's entropy source:
 The diceware software ships with a few word lists, and the default list
 has been deliberately created for generating passwords. It is derived
 from the standard diceware list with additions from the [SecureDrop
-project](https://securedrop.org/). Diceware ships with the better
-crafted [EFF word
-list](https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases),
-but it is not enabled by default, even though diceware recommends using
-it when generating passwords with dice. That is because the EFF list was
-added [later on](https://github.com/ulif/diceware/issues/26). The
-project is currently
-[considering](https://github.com/ulif/diceware/issues/33) making the EFF
-list be the default.
+project](https://securedrop.org/). Diceware ships with the [EFF word
+list](https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases)
+that has words chosen for better recognition, but it is not enabled by
+default, even though diceware recommends using it when generating
+passwords with dice. That is because the EFF list was added [later
+on](https://github.com/ulif/diceware/issues/26). The project is
+currently [considering](https://github.com/ulif/diceware/issues/33)
+making the EFF list be the default.
 
 One disadvantage of diceware is that it doesn't actually show how much
 entropy the generated password has — those interested need to compute it
@@ -218,7 +217,7 @@ the bounds of 24 and 85 bits. That tool is also much less customizable
 than the other two: what you see here is pretty much what you get. The
 4096-word list is also hardcoded in the C source code; it comes from a
 [Usenet sci.crypt
-posting](https://groups.google.com/d/msg/sci.crypt/8QYsDMRPw-o/DXBdw38-PfkJ)+)
+posting](https://groups.google.com/d/msg/sci.crypt/8QYsDMRPw-o/DXBdw38-PfkJ)
 from 1997.
 
 A key feature of xkcdpass and diceware is that you can craft your own

tiny change
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 7cf6180..0cb96b0 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -45,7 +45,7 @@ can figure out your birthday, the name of your first lover, your
 mother's maiden name, where you were last summer, or other
 secrets people think they have.
 
-The only solution here is to use a password randomly-generated
+The only solution here is to use a password randomly generated
 with enough randomness or "entropy" that brute-forcing the password will
 be practically infeasible. Considering that a modern off-the-shelf
 graphics card can guess millions of passwords per second using freely

another dkg review
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index d15a740..7cf6180 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -37,14 +37,15 @@ assert that a good password has the following properties:
 -   memorable: easy to remember for humans
 
 High entropy means that the password should be unpredictable to an
-attacker, for all practical purposes. A password should be random and
-not be based on something else that you know, because that is likely to
-be guessable, no matter how "secret" you believe it is. Yes, with enough
-effort, an attacker can figure out your birthday, the name of your first
-lover, your mother's maiden name, where you were last summer, or other
+attacker, for all practical purposes.  It is tempting (and not
+uncommon) to choose a password based on something else that you know,
+but unfortunately those choices are likely to be guessable, no matter
+how "secret" you believe it is. Yes, with enough effort, an attacker
+can figure out your birthday, the name of your first lover, your
+mother's maiden name, where you were last summer, or other
 secrets people think they have.
 
-The only solution here is to use a completely random password, generated
+The only solution here is to use a password randomly-generated
 with enough randomness or "entropy" that brute-forcing the password will
 be practically infeasible. Considering that a modern off-the-shelf
 graphics card can guess millions of passwords per second using freely
@@ -88,7 +89,7 @@ as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
 "high entropy, compact, and transferable string". Certain APIs are
 specifically crafted to use tokens. [OAuth](https://oauth.net/), for
 example, generates "access tokens" that are random strings that give
-access to services. But in our discussion, we'll use tokens in a broader
+access to services. But in our discussion, we'll use the term "token" in a broader
 sense.
 
 Notice how we removed the "memorable" property and added the "compact"
@@ -221,10 +222,11 @@ posting](https://groups.google.com/d/msg/sci.crypt/8QYsDMRPw-o/DXBdw38-PfkJ)+)
 from 1997.
 
 A key feature of xkcdpass and diceware is that you can craft your own
-word list, which makes dictionary-based attacks much harder. Indeed,
+word list, which can make dictionary-based attacks harder. Indeed,
 with such word-based password generators, the only viable way to crack
 those passwords is to use dictionary attacks, because the password is so
-long that exhaustive searches are not workable. Changing from the
+long that character-based exhaustive searches are not workable, as
+they would take centuries to complete. Changing from the
 default dictionary therefore brings some advantage against attackers.
 This may be yet another "security through obscurity" procedure, however:
 a naive approach may be to use a dictionary localized to your native

remove pandoc conversion cruft
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 14e2774..d15a740 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -75,9 +75,9 @@ localize" (as opposed to words, which are language-specific) and
 But the critical piece is the "memorable" part: it is trivial to
 generate a random string of characters, but those passwords are hard for
 humans to remember. As [xkcd noted](https://xkcd.com/936/),
-"<span>through 20 years of effort, we've successfully trained everyone
+"through 20 years of effort, we've successfully trained everyone
 to use passwords that are hard for human to remember but easy for
-computers to guess</span>". It explains how a series of words is a
+computers to guess". It explains how a series of words is a
 better password than a single word with some characters replaced.
 
 Obviously, you should not need to remember all passwords. Indeed, you
@@ -294,8 +294,8 @@ that this wastes entropy as the use of `tr` discards bits from
 entropy](https://lists.zx2c4.com/pipermail/password-store/2016-December/002554.html)
 when compared to base64. But in the end, the maintainer
 [argued](https://lists.zx2c4.com/pipermail/password-store/2016-December/002559.html)
-that reading "<span>reading from `/dev/urandom` has no \[effect\] on
-`/proc/sys/kernel/random/entropy_avail` on Linux</span>" and dismissed
+that reading "reading from `/dev/urandom` has no [effect] on
+`/proc/sys/kernel/random/entropy_avail` on Linux" and dismissed
 the objection.
 
 Another password manager, [KeePass](http://keepass.info/) uses its own

jon's review
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index f3c37ba..14e2774 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -8,12 +8,12 @@ documentation on how to generate good passwords. There are some
 interesting possibilities for doing so; this article will look at what
 makes a good password and some tools that can be used to generate them.
 
-There is growing concern that our dependence on passwords pose
-fundamental security flaw. First, passwords rely on humans, who can
-be coerced to reveal secret information. Furthermore, passwords are
+There is growing concern that our dependence on passwords poses a
+fundamental security flaw. For example, passwords rely on humans, who
+can be coerced to reveal secret information. Furthermore, passwords are
 "replayable": if your password is revealed or stolen, anyone can
-impersonate you to get access to your most critical assets. Therefore, major
-organizations are trying to move away from single password
+impersonate you to get access to your most critical assets. Therefore,
+major organizations are trying to move away from single password
 authentication. Google, for example, is [enforcing two factor
 authentication for its employees](https://cloud.google.com/security/)
 and is considering abandoning [passwords on phones as
@@ -21,9 +21,9 @@ well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
 although we have yet to see that controversial change implemented.
 
 Yet passwords are still here and are likely to stick around for a long
-time until we figure out a better alternative. Note that in this text I use the word
-"password" instead of "PIN" or "passphrase", which all roughly mean the
-same thing: a small piece of text that users provide to
+time until we figure out a better alternative. Note that in this article
+I use the word "password" instead of "PIN" or "passphrase", which all
+roughly mean the same thing: a small piece of text that users provide to
 prove their identity.
 
 #### What makes a good password?
@@ -31,44 +31,43 @@ prove their identity.
 A "good password" may mean different things to different people. I will
 assert that a good password has the following properties:
 
--   high entropy - hard to guess for machines
--   transferable - easy to communicate for humans or transfer across
-    weird protocols for computers
--   memorable - easy to remember for humans
+-   high entropy: hard to guess for machines
+-   transferable: easy to communicate for humans or transfer across
+    various protocols for computers
+-   memorable: easy to remember for humans
 
 High entropy means that the password should be unpredictable to an
-attacker, for all practical purposes. A password should be random, and
-not be based on something else that
-you know, because that is likely to be guessable, no matter how "secret"
-you believe it is. Yes, with enough effort, an attacker can figure out
-your birthday, the name of your first lover, your mother's maiden name,
-where you were last summer, or other silly secrets people think they
-have.
+attacker, for all practical purposes. A password should be random and
+not be based on something else that you know, because that is likely to
+be guessable, no matter how "secret" you believe it is. Yes, with enough
+effort, an attacker can figure out your birthday, the name of your first
+lover, your mother's maiden name, where you were last summer, or other
+secrets people think they have.
 
 The only solution here is to use a completely random password, generated
 with enough randomness or "entropy" that brute-forcing the password will
-be practically infeasible. Considering that modern off-the-shelf
-graphics card can guess millions of passwords per second, using freely
+be practically infeasible. Considering that a modern off-the-shelf
+graphics card can guess millions of passwords per second using freely
 available software like [hashcat](https://www.hashcat.net/hashcat/), the
 typical requirement of "8 characters" is not considered enough anymore.
 With proper hardware, a powerful rig can crack such passwords offline
-within about a day. Even though the recent [National Institute of Standards and Technology
-(NIST)](https://www.nist.gov/) report still
+within about a day. Even though a recent [US National Institute of
+Standards and Technology (NIST)](https://www.nist.gov/) draft still
 [recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-authenticators)
-a minimum of 8 characters, we now more often hear recommendations of [12
+a minimum of eight characters, we now more often hear recommendations of
+[twelve
 characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
-or [14
+or [fourteen
 characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
 
-A password should also be easily "transferable". Some characters like
-`&` or `!` have special meaning on the web or the shell and can wreak
-havoc when transferred. Certain software also have policies of
-*refusing* (or requiring!) some special characters exactly for that
-reason. Weird characters also make it harder for humans to communicate
-passwords across voice channels or different cultural backgrounds. In a
-more extreme example, the popular Signal software even resorted to
-[using only
-digits](https://whispersystems.org/blog/safety-number-updates/) to
+A password should also be easily "transferable". Some characters, like
+`&` or `!`, have special meaning on the web or the shell and can wreak
+havoc when transferred. Certain software also has policies of *refusing*
+(or requiring!) some special characters exactly for that reason. Weird
+characters also make it harder for humans to communicate passwords
+across voice channels or different cultural backgrounds. In a more
+extreme example, the popular Signal software even resorted to [using
+only digits](https://whispersystems.org/blog/safety-number-updates/) to
 transfer key fingerprints. They outlined that numbers are "easy to
 localize" (as opposed to words, which are language-specific) and
 "visually distinct".
@@ -82,15 +81,15 @@ computers to guess</span>". It explains how a series of words is a
 better password than a single word with some characters replaced.
 
 Obviously, you should not need to remember all passwords. Indeed, you
-may store some in password generators (which we'll look at in another
+may store some in password managers (which we'll look at in another
 article) or write them down in your wallet. In those cases, what you
 need is not a password, but something I would rather call a "token", or,
-as Debian Developer Daniel Kahn Gillmor said in a private email, a
+as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
 "high entropy, compact, and transferable string". Certain APIs are
 specifically crafted to use tokens. [OAuth](https://oauth.net/), for
-example, generates "access tokens" that are basically random strings
-that give access to services. But in our discussion, we'll use tokens in
-a broader sense.
+example, generates "access tokens" that are random strings that give
+access to services. But in our discussion, we'll use tokens in a broader
+sense.
 
 Notice how we removed the "memorable" property and added the "compact"
 one: we want to efficiently convert the most entropy into the shortest
@@ -100,27 +99,26 @@ web sites have an upper limit in the password length. The "compact"
 property applies less to "passwords" than tokens, because I assume that
 you will only use a password in select places: your password manager,
 SSH and OpenPGP keys, your computer login, and encryption keys.
-Everything else should be in a password manager.
-Those tools are generally under your control and should allow large
-enough passwords that the compact property is not particularly
-important.
+Everything else should be in a password manager. Those tools are
+generally under your control and should allow large enough passwords
+that the compact property is not particularly important.
 
 #### Generating secure passwords
 
 We'll look now at how to generate a strong, transferable, and memorable
-password. This is most likely the passwords you will deal with most of
-the time, as security tokens should actually never show up on screen:
-they should be copy-pasted or automatically typed in forms. The password
-generators described here are all operated from the command line. It's
-also interesting to note that password managers often have embedded
-password generators, but usually don't provide an easy way to generate a
-password for the vault itself.
-
-The previously mentioned \#936 cartoon from xkcd is probably a common
-cultural reference in the security crowd and I often use it to explain
-how to choose a good passphrase. It turns out that someone actually
-implemented xkcd author Randall Munroe's suggestion into a program
-called [xkcdpass](https://pypi.python.org/pypi/xkcdpass/):
+password. These are most likely the passwords you will deal with most of
+the time, as security tokens used in other settings should actually
+never show up on screen: they should be copy-pasted or automatically
+typed in forms. The password generators described here are all operated
+from the command line. Password managers often have embedded password
+generators, but usually don't provide an easy way to generate a password
+for the vault itself.
+
+The previously mentioned xkcd cartoon is probably a common cultural
+reference in the security crowd and I often use it to explain how to
+choose a good passphrase. It turns out that someone actually implemented
+xkcd author Randall Munroe's suggestion into a program called
+[xkcdpass](https://pypi.python.org/pypi/xkcdpass/):
 
         $ xkcdpass
         estop mixing edelweiss conduct rejoin flexitime
@@ -136,19 +134,19 @@ passphrase:
         estop mixing edelweiss conduct rejoin flexitime
 
 Note that the above password has 91 bits of entropy, which is about what
-a 15 character password would have, if chosen from uppercase, lowercase,
-digits and 10 symbols:
+a fifteen-character password would have, if chosen at random from
+uppercase, lowercase, digits, and ten symbols:
 
         log2((26 + 26 + 10 + 10)^15) = approx. 92.548875
 
 It's also interesting to note that this is closer to the entropy of a
-15-letter base64 encoded password: since each character is 6 bits, you
-end up with 90 bits of entropy. xkcdpass is scriptable and easy to use.
-You can also customize the word list, separators, and so on with
-different command-line options. By default, xkcdpass uses the [2 of
+fifteen-letter base64 encoded password: since each character is six
+bits, you end up with 90 bits of entropy. xkcdpass is scriptable and
+easy to use. You can also customize the word list, separators, and so on
+with different command-line options. By default, xkcdpass uses the [2 of
 12](http://wordlist.aspell.net/12dicts-readme/#nof12) word list from [12
-dicts](http://wordlist.aspell.net/12dicts/) and is not specifically
-geared towards password generation but has been curated for "common
+dicts](http://wordlist.aspell.net/12dicts/), which is not specifically
+geared toward password generation but has been curated for "common
 words" and words of different sizes.
 
 Another option is the [diceware system](http://diceware.com/). Diceware
@@ -176,36 +174,38 @@ computer's entropy source:
         [...]

(fichier de différences tronqué)
my own final review
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index f3ec250..f3c37ba 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -8,20 +8,11 @@ documentation on how to generate good passwords. There are some
 interesting possibilities for doing so; this article will look at what
 makes a good password and some tools that can be used to generate them.
 
-Recently, the US [National Institute of Standards and Technology
-(NIST)](https://www.nist.gov/) made a new set of recommendations, the [Special
-Publication 800-63-3: Digital Identity
-Guidelines](https://pages.nist.gov/800-63-3/) which outlines new
-standards of password requirements and practices, but that has yet to
-propagate to the industry. The publication also covers more than just
-passwords, but also password policies like expiration and so on, that
-are beyond the scope of this article.
-
 There is growing concern that our dependence on passwords pose
-fundamental security flaw. For example, passwords rely on humans, who can
+fundamental security flaw. First, passwords rely on humans, who can
 be coerced to reveal secret information. Furthermore, passwords are
 "replayable": if your password is revealed or stolen, anyone can
-impersonate you to get access to your most critical assets. Major
+impersonate you to get access to your most critical assets. Therefore, major
 organizations are trying to move away from single password
 authentication. Google, for example, is [enforcing two factor
 authentication for its employees](https://cloud.google.com/security/)
@@ -30,10 +21,9 @@ well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
 although we have yet to see that controversial change implemented.
 
 Yet passwords are still here and are likely to stick around for a long
-time until we figure out a better alternative. I will start by looking
-at basic password hygiene. Note that in this text I use the word
+time until we figure out a better alternative. Note that in this text I use the word
 "password" instead of "PIN" or "passphrase", which all roughly mean the
-same thing: a small piece of text that users are expected to provide to
+same thing: a small piece of text that users provide to
 prove their identity.
 
 #### What makes a good password?
@@ -47,8 +37,8 @@ assert that a good password has the following properties:
 -   memorable - easy to remember for humans
 
 High entropy means that the password should be unpredictable to an
-attacker, for all practical purposes. It may seem obvious to some, but a
-password should be random. It should not be based on something else that
+attacker, for all practical purposes. A password should be random, and
+not be based on something else that
 you know, because that is likely to be guessable, no matter how "secret"
 you believe it is. Yes, with enough effort, an attacker can figure out
 your birthday, the name of your first lover, your mother's maiden name,
@@ -61,9 +51,11 @@ be practically infeasible. Considering that modern off-the-shelf
 graphics card can guess millions of passwords per second, using freely
 available software like [hashcat](https://www.hashcat.net/hashcat/), the
 typical requirement of "8 characters" is not considered enough anymore.
-With proper hardware, a powerful offline rig can crack such passwords
-within about a day. Even though the NIST report still recommends a
-minimum of 8 characters, we now more often hear recommendations of [12
+With proper hardware, a powerful rig can crack such passwords offline
+within about a day. Even though the recent [National Institute of Standards and Technology
+(NIST)](https://www.nist.gov/) report still
+[recommends](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-authenticators)
+a minimum of 8 characters, we now more often hear recommendations of [12
 characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
 or [14
 characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
@@ -93,7 +85,7 @@ Obviously, you should not need to remember all passwords. Indeed, you
 may store some in password generators (which we'll look at in another
 article) or write them down in your wallet. In those cases, what you
 need is not a password, but something I would rather call a "token", or,
-as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
+as Debian Developer Daniel Kahn Gillmor said in a private email, a
 "high entropy, compact, and transferable string". Certain APIs are
 specifically crafted to use tokens. [OAuth](https://oauth.net/), for
 example, generates "access tokens" that are basically random strings
@@ -107,10 +99,11 @@ For example, some bank cards only allow 5-digit security PINs and most
 web sites have an upper limit in the password length. The "compact"
 property applies less to "passwords" than tokens, because I assume that
 you will only use a password in select places: your password manager,
-SSH and OpenPGP keys, your computer login, and encryption keys, period.
+SSH and OpenPGP keys, your computer login, and encryption keys.
+Everything else should be in a password manager.
 Those tools are generally under your control and should allow large
 enough passwords that the compact property is not particularly
-important. Everything else should be in a password manager.
+important.
 
 #### Generating secure passwords
 
@@ -179,7 +172,9 @@ computer's entropy source:
         Please roll 5 dice (or a single dice 5 times).
         What number shows dice number 1? 4
         What number shows dice number 2? 2
-        What number shows dice number 3? [...]
+        What number shows dice number 3? 6
+        [...]
+        Aspire O's Ester Court Born Pk
 
 The diceware software ships with a few word lists, and the default has
 been deliberately geared toward generating passwords. It is derived from
@@ -188,16 +183,18 @@ project](https://securedrop.org/). It is interesting to note that, while
 diceware ships with the better crafted [EFF word
 list](https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases),
 it is not enabled by default, even though diceware recommends using it
-when generating passwords with dice. This is probably because the EFF
-list was added [later on](https://github.com/ulif/diceware/issues/26).
+when generating passwords with dice. That is because the EFF
+list was added [later on](https://github.com/ulif/diceware/issues/26)
+and they are
+[considering making the EFF list the default](https://github.com/ulif/diceware/issues/33).
 
 One disadvantage of diceware is that it doesn't actually tell you how
 much entropy the generated password has — you need to compute it
 yourself. The actual number depends on the word list: the default word
-list has about 13 bits of entropy per word, which means the default 6
-word passwords have about 78 bits of entropy:
+list has 13 bits of entropy per word (being exactly 8192 words long), which means the default 6
+word passwords have 78 bits of entropy:
 
-        log2(7776) * 6 = approx. 77.548875
+        log2(8192) * 6 = 78
 
 Both of these programs are rather new, having, for example, entered Debian
 only after the last stable release, so they may not be directly available for
@@ -218,27 +215,40 @@ better control over the level of entropy:
 For some reason, `passwdqc` restricts the entropy of passwords between
 the bounds of 24 and 85 bits. That tool is also much less customizable
 than the other two: what you see here is pretty much what you get. The
-word list is also hardcoded in the C source code.
+4096 word list is also hardcoded in the C source code and comes from
+an
+[old usenet post](https://groups.google.com/d/msg/sci.crypt/8QYsDMRPw-o/DXBdw38-PfkJ)
+from 1997...
 
 A key feature of xkcdpass and diceware is that you can craft your own
 word list, which makes dictionary-based attacks much harder. Indeed,
 with word-based password generators, the only viable way to crack those
 passwords is to use dictionary attacks, because the password is so long
 that exhaustive searches are not workable. Changing from the default
-dictionary therefore brings a notable advantage against attackers. This
+dictionary therefore brings some advantage against attackers. This
 may be yet another "security through obscurity" procedure, however: an
 naive approach may be to use a dictionary localized to your native
 language (for example, in my case, French), but that would deter only an
 attacker that doesn't do basic research about you, so that advantage is
 quickly lost to determined attackers.
 
+One should also note that the actual entropy of the password doesn't
+depend on the actual word list chosen, but its length. Furthermore, a
+larger dictionnary only expands the search space logarithmically, or,
+in other words, doubling the word list length only adds a single bit
+of entropy so it is actually much better to add a word to your
+password than a word to the word list that generates it.
+
 #### Generating security tokens
 
 As mentioned before, most password managers feature a way to generate
 strong security tokens, with different policies (symbols or not, length,
 etc). In general, you should use your password manager's
 password-generation functionality to generate tokens for sites you
-visit. But how are those functionalities implemented?
+visit. But how are those functionalities implemented and what can you
+do if your password manager (for example Firefox's [master password
+feature](https://support.mozilla.org/en-US/kb/use-master-password-protect-stored-logins))
+does not actually generate passwords for you?
 
 [`pass`](https://www.passwordstore.org/), the standard UNIX password
 manager, delegates this task to the widely known
@@ -253,44 +263,43 @@ email](https://lists.zx2c4.com/pipermail/password-store/2016-December/002534.htm
 It turns out that there are lots of ways to skin this particular cat. I
 was suggesting the following pipeline to generate the password:
 
-        $ head -c $entropy /dev/random | base64 | tr -d '\n='
+        head -c $entropy /dev/random | base64 | tr -d '\n='
 
 The above command takes a certain number from the kernel
 (`head -c $entropy /dev/random`) encodes that using the `base64`
 algorithm and strips out the trailing equal sign and newlines (for large
 passwords). This is what Gillmor described as a "high-entropy compact
-printable/transferable string". The priority, in this specific case, is
+printable/transferable string". The priority, in this case, is
 to have a token that is as compact as possible with the given entropy,
-while at the same time use a character set that should not cause as
+while at the same time use a character set that should cause as
 little trouble as possible on sites that restrict the characters you can
 use. Gillmor is a co-maintainer of the
 [Assword](https://finestructure.net/assword/) password manager, which
-chose base64 because it is widely available and understood, and only
+chose base64 because it is widely available and understood and only
 takes up 33% more space than the original 8-bit binary encoding. After
-an interesting discussion, the pass maintainer, Jason A. Donenfeld,
+a lengthy discussion, the pass maintainer, Jason A. Donenfeld,
 chose the following pipeline:
 
-        CHARACTER_SET="${PASSWORD_STORE_CHARACTER_SET:-[:graph:]}"
-        CHARACTER_SET_NO_SYMBOLS="${PASSWORD_STORE_CHARACTER_SET_NO_SYMBOLS:-[:alnum:]}"
-        [...]
         read -r -n $length pass < <(LC_ALL=C tr -dc "$characters" < /dev/urandom)
 
 The above is similar, except it uses `tr` to directly to read characters

(fichier de différences tronqué)
small changes after jake's comments
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 0363e9a..f3ec250 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -9,16 +9,16 @@ interesting possibilities for doing so; this article will look at what
 makes a good password and some tools that can be used to generate them.
 
 Recently, the US [National Institute of Standards and Technology
-(NIST)](https://www.nist.gov/) made a new recommendation, the [Special
-Publication 800-63-3: Digital Authentication
+(NIST)](https://www.nist.gov/) made a new set of recommendations, the [Special
+Publication 800-63-3: Digital Identity
 Guidelines](https://pages.nist.gov/800-63-3/) which outlines new
 standards of password requirements and practices, but that has yet to
 propagate to the industry. The publication also covers more than just
 passwords, but also password policies like expiration and so on, that
 are beyond the scope of this article.
 
-I also recognize that we should move away from passwords where possible.
-They pose a fundamental security flaw: the reliance on humans, who can
+There is growing concern that our dependence on passwords pose
+fundamental security flaw. For example, passwords rely on humans, who can
 be coerced to reveal secret information. Furthermore, passwords are
 "replayable": if your password is revealed or stolen, anyone can
 impersonate you to get access to your most critical assets. Major
@@ -199,11 +199,13 @@ word passwords have about 78 bits of entropy:
 
         log2(7776) * 6 = approx. 77.548875
 
-Both of these programs are recent, having, for example, entered Debian
-only after the last stable release, so they may not be available for
+Both of these programs are rather new, having, for example, entered Debian
+only after the last stable release, so they may not be directly available for
 your distribution. The diceware method, of course, only needs a set of
-dice and a word list, so that is much more portable. But if you insist
-on using an older computer to generate your passphrase, you can take a
+dice and a word list, so that is much more portable, and both diceware
+and xkcdpass can be installed through
+[Pip](https://pip.pypa.io/). However, if this is all too complicated,
+you can take a
 look at [Openwall's passwdqc](http://www.openwall.com/passwdqc/), which
 generates more memorable passphrases while at the same time allowing for
 better control over the level of entropy:
@@ -220,7 +222,7 @@ word list is also hardcoded in the C source code.
 
 A key feature of xkcdpass and diceware is that you can craft your own
 word list, which makes dictionary-based attacks much harder. Indeed,
-with such pattern-based software, the only viable way to crack those
+with word-based password generators, the only viable way to crack those
 passwords is to use dictionary attacks, because the password is so long
 that exhaustive searches are not workable. Changing from the default
 dictionary therefore brings a notable advantage against attackers. This

first LWN unpublished draft
diff --git a/blog/passwords-entropy.mdwn b/blog/passwords-entropy.mdwn
index 3a1272d..0363e9a 100644
--- a/blog/passwords-entropy.mdwn
+++ b/blog/passwords-entropy.mdwn
@@ -1,351 +1,308 @@
-How to reliably generate passwords and tokens
-=============================================
+Reliably generating good passwords
+==================================
 
 Passwords are used everywhere in our modern life. Between your email
 account and your bank card, a lot of critical security infrastructure
-relies on "something you know", a password. Yet there is little
-standard documentation on how to generate good passwords. Recently,
-[NIST](https://www.nist.gov/) made a new recommendation, the
-[Special Publication 800-63-3: Digital Authentication Guidelines](https://pages.nist.gov/800-63-3/)
-which outlines new standards of password requirements and practices,
-but that has yet to propagate to the industry. The publication also covers more than
-just passwords, but also password policies like expiration and so on,
-that are beyond the scope of this article.
-
-I also recognize that we should move away from passwords where
-possible. They pose a fundamental security flaw: the reliance on
-humans, which can be coerced to reveal secret
-information. Furthermore, passwords are "replayable": if your password
-is revealed or stolen, anyone can impersonate you to get access to
-your most critical assets. Major
+relies on "something you know", a password. Yet there is little standard
+documentation on how to generate good passwords. There are some
+interesting possibilities for doing so; this article will look at what
+makes a good password and some tools that can be used to generate them.
+
+Recently, the US [National Institute of Standards and Technology
+(NIST)](https://www.nist.gov/) made a new recommendation, the [Special
+Publication 800-63-3: Digital Authentication
+Guidelines](https://pages.nist.gov/800-63-3/) which outlines new
+standards of password requirements and practices, but that has yet to
+propagate to the industry. The publication also covers more than just
+passwords, but also password policies like expiration and so on, that
+are beyond the scope of this article.
+
+I also recognize that we should move away from passwords where possible.
+They pose a fundamental security flaw: the reliance on humans, who can
+be coerced to reveal secret information. Furthermore, passwords are
+"replayable": if your password is revealed or stolen, anyone can
+impersonate you to get access to your most critical assets. Major
 organizations are trying to move away from single password
-authentication. Google, for example, is
-[enforcing two factor authentication for their employees](https://cloud.google.com/security/)
-and is considering abandoning
-[passwords on phones as well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
+authentication. Google, for example, is [enforcing two factor
+authentication for its employees](https://cloud.google.com/security/)
+and is considering abandoning [passwords on phones as
+well](http://boingboing.net/2016/05/23/google-may-abandon-passwords-f.html),
 although we have yet to see that controversial change implemented.
 
 Yet passwords are still here and are likely to stick around for a long
-time until we figure out a better alternative. This article aims at
-covering basic password hygiene techniques and software. Note that in this
-text I use the word "password" instead of "PIN" or "passphrase", which
-all roughly mean the same thing: a small piece of text that users are
-expected to provide to prove their identity.
-
-What is a good password
------------------------
-
-A "good password" may mean different things to different people. I
-will assert that a good password has the following properties:
-
- * high entropy - hard to guess for machines
- * transferable - easy to communicate for humans or transfer across
-   weird protocols for computers
- * memorable - easy to remember for humans
-
-High entropy means that the password should be unprecticable to an
-attacker, for all practical purposes. It may seem obvious to some, but
-a password should be random. It should not be based on something else
-that you know, because that is likely to be guessable by an attacker,
-however "secret" you believe it is. Yes, with enough efforts, an
-attacker can figure out your birthday, the name of your first lover,
-your mother's maiden name, where you were last summer or other silly
-secrets people think they have. The only solution here is to use a
-completely random password, generated with enough randomness or
-"entropy" that brute-forcing the password will be practically
-unfeasible. Considering that off the shelf modern graphics card can
-guess millions of passwords per second, using freely available
-software like [hashcat](https://www.hashcat.net/hashcat/), the typical
-requirement of "8 characters" is not considered enough anymore. With
-proper hardware, a powerful offline rig can crack such passwords
-within about a day.
-Even though the NIST report still recommends a minimum of 8
-characters, we now more often hear recommendations of
-[12 characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
-or
-[14 characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
+time until we figure out a better alternative. I will start by looking
+at basic password hygiene. Note that in this text I use the word
+"password" instead of "PIN" or "passphrase", which all roughly mean the
+same thing: a small piece of text that users are expected to provide to
+prove their identity.
+
+#### What makes a good password?
+
+A "good password" may mean different things to different people. I will
+assert that a good password has the following properties:
+
+-   high entropy - hard to guess for machines
+-   transferable - easy to communicate for humans or transfer across
+    weird protocols for computers
+-   memorable - easy to remember for humans
+
+High entropy means that the password should be unpredictable to an
+attacker, for all practical purposes. It may seem obvious to some, but a
+password should be random. It should not be based on something else that
+you know, because that is likely to be guessable, no matter how "secret"
+you believe it is. Yes, with enough effort, an attacker can figure out
+your birthday, the name of your first lover, your mother's maiden name,
+where you were last summer, or other silly secrets people think they
+have.
+
+The only solution here is to use a completely random password, generated
+with enough randomness or "entropy" that brute-forcing the password will
+be practically infeasible. Considering that modern off-the-shelf
+graphics card can guess millions of passwords per second, using freely
+available software like [hashcat](https://www.hashcat.net/hashcat/), the
+typical requirement of "8 characters" is not considered enough anymore.
+With proper hardware, a powerful offline rig can crack such passwords
+within about a day. Even though the NIST report still recommends a
+minimum of 8 characters, we now more often hear recommendations of [12
+characters](https://blog.codinghorror.com/your-password-is-too-damn-short/)
+or [14
+characters](https://technet.microsoft.com/en-us/library/hh994560.aspx).
 
 A password should also be easily "transferable". Some characters like
 `&` or `!` have special meaning on the web or the shell and can wreak
 havoc when transferred. Certain software also have policies of
 *refusing* (or requiring!) some special characters exactly for that
 reason. Weird characters also make it harder for humans to communicate
-passwords across voice channels or different cultural backgrounds. In
-a more extreme example, the popular Signal software even resorted to
-[using only digits](https://whispersystems.org/blog/safety-number-updates/)
-to transfer key fingerprints. They outlined that numbers are "easy to
+passwords across voice channels or different cultural backgrounds. In a
+more extreme example, the popular Signal software even resorted to
+[using only
+digits](https://whispersystems.org/blog/safety-number-updates/) to
+transfer key fingerprints. They outlined that numbers are "easy to
 localize" (as opposed to words, which are language-specific) and
 "visually distinct".
 
-But critical part of passwords is the "memorable" part: it is trivial
-to generate a random string of characters, but as those passwords are
-hard for humans to remember. As
-[XKCD explained](https://xkcd.com/936/), "through 20 years of effort,
-we've successfully trained everyone to use passwords that are hard for
-human to remember but easy for computers to guess". The XKCD cartoon
-explains how a series of words is a better password than a single word
-with some characters replaced.
+But the critical piece is the "memorable" part: it is trivial to
+generate a random string of characters, but those passwords are hard for
+humans to remember. As [xkcd noted](https://xkcd.com/936/),
+"<span>through 20 years of effort, we've successfully trained everyone
+to use passwords that are hard for human to remember but easy for
+computers to guess</span>". It explains how a series of words is a
+better password than a single word with some characters replaced.
 
 Obviously, you should not need to remember all passwords. Indeed, you
-may store some in password generators (which we'll cover in the next
-article) or write them down in your wallet. In those case, what you
-need is not a password, but something I would rather call a "token",
-or, as Debian Developer Daniel Kahn Gillmor (dkg) said in a private
-email, a "high entropy, compact and transferable string". Certain APIs
-are specifically crafted to use tokens. Oauth, for example, generates
-"access tokens" which are basically random strings that give access to
-services. But in our discussion, we'll use tokens in a broader sense.
+may store some in password generators (which we'll look at in another
+article) or write them down in your wallet. In those cases, what you
+need is not a password, but something I would rather call a "token", or,
+as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a
+"high entropy, compact, and transferable string". Certain APIs are
+specifically crafted to use tokens. [OAuth](https://oauth.net/), for
+example, generates "access tokens" that are basically random strings
+that give access to services. But in our discussion, we'll use tokens in
+a broader sense.
 
 Notice how we removed the "memorable" property and added the "compact"
-one: we want to efficiently convert the most entropy into the
-shortest password possible, to work around possibly limiting password
-policies. For example, some bank cards only allow 5-digit security
-PINs and most websites have an upper limit in the password length. The
-"compact" property applies less to "passwords" than tokens, because I
-assume that you will use only a passwords in a select places: your
-password manager, SSH and OpenPGP keys, your computer login and
-encryption keys, period. Those tools are generally under your control
-and should allow large enough passwords that the compact property is
-not important anymore. Everything else should be in a password
-manager.
-
-Generating secure passwords

(fichier de différences tronqué)
refer to nist for hash rounds?
diff --git a/blog/password-hashers.mdwn b/blog/password-hashers.mdwn
index 9d99f62..d5a4cb4 100644
--- a/blog/password-hashers.mdwn
+++ b/blog/password-hashers.mdwn
@@ -329,6 +329,9 @@ and shove everything else in a password manager".
 internal notes
 --------------
 
+link to the NIST report for hash rounds?
+https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/
+
 mental hash:
 
 http://scilogs.spektrum.de/hlf/mental-cryptography-and-good-passwords/

Created . Edited .