From: Jeff King <peff@peff.net>
To: M Hickford <mirth.hickford@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: The enduring popularity of git-credential-store
Date: Tue, 8 Nov 2022 10:41:34 -0500 [thread overview]
Message-ID: <Y2p4rhiOphuOM0VQ@coredump.intra.peff.net> (raw)
In-Reply-To: <CAGJzqskRYN49SeS8kSEN5-vbB_Jt1QvAV9QhS6zNuKh0u8wxPQ@mail.gmail.com>
On Tue, Nov 08, 2022 at 10:50:33AM +0000, M Hickford wrote:
> Among StackOverflow users [1], git-credential-store appears several
> times more popular than any other credential helper. Does this make
> anyone else uneasy? The docs warn that git-credential-store "stores
> your passwords unencrypted on disk" [2]. Are users sacrificing
> security for convenience?
>
> Firstly, how grave is storing credentials in plaintext? Software
> development guidelines such as CWE discourage storing credentials in
> plaintext [3]. Password managers in desktop environments, mobile
> operating systems and web browsers typically encrypt passwords on disk
> and guard them behind a master password.
So obviously credential-store is the least-common-denominator of
storage, and it should (and does) come with a big warning. However, I
wonder if it actually is a reasonable solution for a lot of people:
- "passwords" these days are often not keys-to-the-kingdom, but
special-use tokens that allow limited access.
- the threat model for many people assumes that their local system is
trusted. Git needs the credential in plaintext at _some_ point. If
your local user account is compromised, people can read your
passwords. But they can also trojan Git, etc.
I do think one is much worse than the other. Stealing a password
once is easier than installing a malicious Git that records the
password. And a stolen password can be used many times, as opposed
to a malicious Git that misbehaves when run by the local user.
So yeah, obviously using a system password store is better if you can.
But it's sometimes difficult to set up, especially when automation is
involved. And I think it buys people less than they might think.
Especially for git's credential helpers, which are meant to be
scriptable, you can just _ask_ them to retrieve the password from the
system store. So they are really only protecting the credentials at
rest. And other approaches, like full-disk encryption, may be enough for
some people.
You asked "does it make anyone else uneasy?". A little, I guess, because
like you I'm sure there are people who are using it only because they
don't know better, and are not heeding the warnings. But it may also be
that some people are using it as a part of a reasoned tradeoff.
So if you're asking "should we stop shipping credential-store", I'm not
_completely_ opposed, but I do wonder if its popularity means it is
better-than-nothing for some folks. If you're asking how we can nudge
people to better systems, that seems like a pure win. But I also don't
know how to do it. ;)
> Secondly, the docs recommend git-credential-cache [2] which ships with
> Git and is equally easy to configure. So why isn't it more popular? My
> hypothesis: while caching works great for passwords typed from memory,
> the combination of caching with personal access tokens has poor
> usability. The unmemorised token is lost when the cache expires, so
> the user has to generate a new token every session. I suspect GitHub's
> 2021 decision to stop accepting passwords [4] may have inadvertently
> pushed users from 'cache' to 'store'.
Another big problem with credential-cache is that it requires Unix
sockets, so it doesn't run on Windows.
> Thirdly, why doesn't everyone use SSH keys? Unlike HTTP remotes,
> upfront set-up is necessary to clone a public repo. For users
> unfamiliar with SSH, this set-up may be intimidating. Introducing
> users new to Git to SSH at the same time is a significant cognitive
> load.
Yes, I think it's just that it's too hard to set up. In the early days
of GitHub, people getting confused and flustered by setting up SSH keys
was one of the biggest barriers to adoption (which is the whole reason I
improved the https auth flow, including adding credential helpers).
I do wonder what that's like these days, though. When people could
switch to just using their password from the website, I'm sure it was
much easier than learning about ssh keys. But these days you have to
learn about PATs, etc. I don't know if people do that by hand, or rely
on tools to help (like GitHub Desktop, or probably gh-cli).
> Any ideas how to improve the security of the average Git user?
All of which is to say that I have no clue what the user experience is
like these days, or what drives people in their decision about which
tools to use. ;)
I do stand by credential-store as not being _completely_ without value,
but I also recognize that its existence may cause people to make bad
decisions. If you have a plan, I'm all-ears.
-Peff
next prev parent reply other threads:[~2022-11-08 15:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 10:50 The enduring popularity of git-credential-store M Hickford
2022-11-08 12:00 ` Michal Suchánek
2022-11-08 15:41 ` Jeff King [this message]
2022-11-08 21:03 ` Taylor Blau
2023-02-11 7:11 ` M Hickford
2022-11-08 22:52 ` brian m. carlson
2022-11-12 2:30 ` M Hickford
2022-11-17 17:17 ` Matthew John Cheetham
2022-11-17 18:51 ` Jeff King
2022-11-17 19:29 ` Lessley Dennington
2022-11-17 20:43 ` Jeff King
2023-05-29 9:53 ` M Hickford
2023-05-28 19:33 ` M Hickford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2p4rhiOphuOM0VQ@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=mirth.hickford@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).