** Tags added: password-storage

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/2038875

Title:
  Snap uses hardcoded key and salt for password and cookie encryption

Status in chromium-browser package in Ubuntu:
  New

Bug description:
  A working Ubuntu install includes Gnome which includes the gnome-
  keyring. The snap version of Ubuntu does not make use of it. On an
  install of Debian with Gnome, the key ring is used. However, with
  Ubuntu everything is encrypted with the static key of peanuts and the
  salt of saltysalt, and openly accessible as sqlite databases in
  ~/snap/chromium/common/chromium, including passwords from the browser
  and the cookies.

  This should probably be fixed. If a laptop is physically compromised
  it's trivial to decrypt this with a tool like xbrowser.

  You can verify that gnome-libcrypt isn't chosen by default with
  --enable-logging=stderr --v=1 redirect stderr to a log and look for
  Crypt.

  You can see /why/ gnome-libcrypt isn't chosen with chromium
  --password-store=gnome-libcrypt --enable-logging=stderr --v=1 and
  again looking for messages with Crypt.

  I don't think this is a vulnerability per se, Chrome ships in Debian
  with the ability to use a basic store too. But it's an undesirable
  configuration and a regression from Debian when it's run on a platform
  with gnome and libsecret, and only doesn't work because of snap.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2038875/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to