Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #72175 > unrolled thread
| Started by | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| First post | 2015-10-08 07:55 +0200 |
| Last post | 2015-10-13 21:42 +0200 |
| Articles | 20 on this page of 283 — 35 participants |
Back to article view | Back to comp.lang.c
Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-08 07:55 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-08 07:57 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-08 08:01 +0200
Re: Firefox improvements. Robert Baer <robertbaer@localnet.com> - 2015-10-09 01:08 -0700
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-10 13:08 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-10 13:09 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-11 19:03 +0200
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 13:13 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-11 19:55 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 16:02 -0400
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-11 21:45 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-11 17:01 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-11 22:18 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 18:45 -0400
Re: Firefox improvements. "Osmium" <r124c4u102@comcast.net> - 2015-10-11 18:03 -0500
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 19:24 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-11 21:07 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 03:53 +0100
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 03:50 +0100
Re: Firefox improvements. "Osmium" <r124c4u102@comcast.net> - 2015-10-11 17:13 -0500
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 03:55 +0100
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 01:08 -0500
Re: Firefox improvements. Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 11:53 -0700
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-19 16:58 -0400
Re: Firefox improvements. Keith Thompson <kst-u@mib.org> - 2015-10-19 14:32 -0700
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-19 18:26 -0400
Re: Firefox improvements. Keith Thompson <kst-u@mib.org> - 2015-10-20 07:55 -0700
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-20 16:35 +0100
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-11 20:51 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 21:05 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-12 01:08 +0000
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 03:59 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 23:08 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 04:41 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 00:16 -0400
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 00:37 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 05:46 +0100
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 00:56 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 06:18 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 02:22 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 08:44 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 02:23 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 08:47 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 03:59 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 09:14 +0100
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-12 12:08 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 08:59 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 14:25 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 12:20 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 16:27 +0000
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 11:20 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 16:01 +0000
Re: Firefox improvements. Geoff <geoff@invalid.invalid> - 2015-10-13 16:16 -0700
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 23:27 +0000
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-15 21:41 +0200
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 22:43 +0000
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-16 04:44 +0200
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-16 07:51 -0400
Re: Firefox improvements. Keith Thompson <kst-u@mib.org> - 2015-10-16 08:27 -0700
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-16 13:21 -0400
Re: Firefox improvements. Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2015-10-13 11:31 -0400
Re: Firefox improvements. Jeff Liebermann <jeffl@cruzio.com> - 2015-10-13 08:45 -0700
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 16:03 +0000
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 17:46 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 13:10 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-12 20:01 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-13 00:44 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 12:25 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-13 16:40 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 13:02 -0400
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 18:16 +0100
Re: Firefox improvements. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-13 11:32 -0600
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:53 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 20:27 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-14 01:45 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 21:58 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-14 02:13 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:29 -0400
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-15 01:46 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 01:01 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 21:16 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 01:19 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 22:07 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 22:22 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 22:19 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 12:51 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 12:59 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 09:09 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 13:18 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 09:29 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 09:30 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 09:31 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:09 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 22:47 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 21:22 -0400
Re: Firefox improvements. JW <none@dev.null> - 2015-10-16 06:14 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:09 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:07 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 16:24 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 22:50 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:02 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 17:12 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:50 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 18:01 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 20:06 -0400
Re: Firefox improvements. Jakob Bohm <jb-usenet@wisemo.com> - 2015-10-16 02:37 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 07:32 +0200
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-15 14:05 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 19:10 +0100
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-15 14:46 -0400
Re: Firefox improvements. David Brown <david.brown@hesbynett.no> - 2015-10-15 21:28 +0200
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-16 00:19 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 21:31 -0400
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-15 17:51 -0700
Re: Firefox improvements. gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-16 01:41 +0000
Re: Firefox improvements. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-14 20:35 -0600
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-15 21:53 +0200
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 22:18 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 12:46 +0100
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-15 09:18 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-14 02:13 +0000
Re: Firefox improvements. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-13 21:32 -0600
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 00:21 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:30 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 21:09 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 13:20 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 09:07 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-14 04:49 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 00:56 -0400
Re: Firefox improvements. Keith Thompson <kst-u@mib.org> - 2015-10-13 22:39 -0700
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 08:40 +0100
Re: Firefox improvements. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-14 15:01 -0600
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 19:13 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:33 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 19:15 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 12:42 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:32 -0400
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 13:26 -0500
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 07:48 +0200
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 02:09 -0700
Re: Firefox improvements. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-21 11:10 +0100
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 03:45 -0700
Re: Firefox improvements. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-21 13:05 +0100
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-21 11:25 -0500
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 07:53 +0200
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 18:45 +0100
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-13 15:47 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 22:17 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 21:59 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 20:35 -0400
Re: Firefox improvements. Richard Damon <Richard@Damon-Family.org> - 2015-10-13 22:28 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 04:00 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 23:10 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 04:19 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 00:15 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 08:29 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:39 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 21:10 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 22:24 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 22:31 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:16 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 16:25 -0400
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 08:03 +0200
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-14 22:50 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:19 -0400
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-14 22:26 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 22:38 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 12:20 +0100
Re: Firefox improvements. "Osmium" <r124c4u102@comcast.net> - 2015-10-13 22:54 -0500
Re: Firefox improvements. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-14 04:24 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:47 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 23:01 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:44 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 21:11 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 22:26 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 18:48 +0000
Re: Firefox improvements. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-13 13:24 -0600
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 22:23 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 20:36 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:59 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 20:35 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 02:16 +0100
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-13 18:54 -0700
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 04:05 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:52 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:49 -0400
Re: Firefox improvements. "Osmium" <r124c4u102@comcast.net> - 2015-10-14 23:07 -0500
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 07:12 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 12:58 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 20:49 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 12:26 -0400
Re: Firefox improvements. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 03:02 +0000
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 12:19 -0500
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-16 17:17 -0400
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-20 22:13 -0500
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 14:13 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 15:04 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 12:30 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 16:43 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 02:29 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 08:53 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 08:50 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 14:18 +0100
Re: Firefox improvements. Jeroen Belleman <jeroen@nospam.please> - 2015-10-12 16:50 +0200
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 12:12 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 17:33 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 16:32 +0000
Re: Firefox improvements. Richard Damon <Richard@Damon-Family.org> - 2015-10-12 21:20 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 21:43 -0400
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-13 08:03 +0200
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 07:18 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 07:28 +0100
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 10:16 +0100
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-13 04:35 -0700
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 12:57 +0100
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 13:29 +0100
Re: Firefox improvements. David Brown <david.brown@hesbynett.no> - 2015-10-13 14:41 +0200
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 13:53 +0100
Re: Firefox improvements. David Brown <david.brown@hesbynett.no> - 2015-10-13 16:24 +0200
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 16:12 +0000
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-13 16:39 +0000
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 18:51 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:55 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:47 -0400
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 18:13 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 19:03 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:57 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 22:02 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 22:04 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 12:15 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 16:37 +0000
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 12:46 -0400
Re: Firefox improvements. Brian Gladman <blindanagram@nowhere.net> - 2015-10-12 18:01 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 13:14 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 15:12 +0000
Re: Firefox improvements. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 03:06 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 12:28 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 02:30 -0400
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 23:58 -0700
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 09:01 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 08:54 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 14:24 +0100
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-12 07:07 -0700
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 13:02 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 15:24 +0000
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 00:18 -0400
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 16:31 -0500
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 15:55 -0500
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-16 17:33 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-17 01:32 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-17 01:12 -0400
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-17 12:53 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-17 19:32 -0400
Re: Firefox improvements. Chad <cdalten@gmail.com> - 2015-10-17 20:29 -0700
Re: Firefox improvements. gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-18 08:10 +0000
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-18 11:08 -0500
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-18 17:15 -0400
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-18 12:42 -0400
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-17 10:01 +0200
Trusting password managers [Re: Firefox improvements.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-18 00:34 -0500
Re: Trusting password managers [Re: Firefox improvements.] James Kuyper <jameskuyper@verizon.net> - 2015-10-18 11:55 -0400
Re: Trusting password managers [Re: Firefox improvements.] DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-18 17:13 -0400
Re: Trusting password managers [Re: Firefox improvements.] DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-19 06:47 -0400
Re: Trusting password managers [Re: Firefox improvements.] Neon John <no@never.com> - 2015-10-18 13:25 -0400
Re: Trusting password managers [Re: Firefox improvements.] Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 16:18 -0700
Re: Trusting password managers [Re: Firefox improvements.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-19 18:37 -0500
Re: Trusting password managers [Re: Firefox improvements.] Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 11:54 -0700
Re: Firefox improvements. rpw3@rpw3.org (Rob Warnock) - 2015-10-12 05:52 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 02:35 -0400
Password crackers are not naive [Was: Firefox improvements.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-18 01:07 -0500
Re: Password crackers are not naive [Was: Firefox improvements.] "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 08:16 +0200
Re: Password crackers are not naive [Was: Firefox improvements.] David Malone <dwmalone@walton.maths.tcd.ie> - 2015-10-21 15:54 +0000
Re: Password crackers are not naive [Was: Firefox improvements.] DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-21 11:57 -0400
Re: Password crackers are not naive [Was: Firefox improvements.] dplatt@coop.radagast.org (Dave Platt) - 2015-10-21 11:17 -0700
Re: Firefox improvements. Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 10:38 -0700
Re: Firefox improvements. Rosario19 <Ros@invalid.invalid> - 2015-10-12 09:56 +0200
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-18 01:25 -0500
Re: Firefox improvements. fir <profesor.fir@gmail.com> - 2015-10-14 00:32 -0700
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 08:47 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 09:17 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 09:36 +0200
Re: Firefox improvements. bartekltg <bartekltg@gmail.com> - 2015-10-11 23:07 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-13 21:42 +0200
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-12 08:54 -0400 |
| Message-ID | <q7bn1blfjcf6ahss12d44g7iq10mn9m3nf@4ax.com> |
| In reply to | #72599 |
On Mon, 12 Oct 2015 09:01:24 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >On 12/10/15 07:30, DecadentLinuxUserNumeroUno wrote: >> On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> >> Gave us: >> >>> Restrictions on allowable keys make brute force easier, not harder. >> >> No. It is harder because the set of possible keys is larger, and >> brute force means each one is attempted whole. > >Let us consider, at the risk of confusing you even more, a five-bit >password. We have two sites, one which accepts *any* five-bit password, >and one that requires you to have at least two clear bits and at least >two set bits. > >Site A - all 5-bit passwords are acceptable >00000 00001 00010 00011 00100 00101 00110 00111 >01000 01001 01010 01011 01100 01101 01110 01111 >10000 10001 10010 10011 10100 10101 10110 10111 >11000 11001 11010 11011 11100 11101 11110 11111 > >32 possible passwords. Worst case brute force: 32 guesses. Mean: 16. > >Site B - 5-bit passwords must have at least two clear and two set bits. >xxxxx xxxxx xxxxx 00011 xxxxx 00101 00110 00111 >xxxxx 01001 01010 01011 01100 01101 01110 xxxxx >xxxxx 10001 10010 10011 10100 10101 10110 xxxxx >11000 11001 11010 xxxxx 11100 xxxxx xxxxx xxxxx > >By restricting the kinds of passwords available to the user, we now have >only 20 possible passwords. Worst case brute force: 20 guesses. Mean: 10. > >Restrictions decrease the amount of work required for brute force. The mistake you are making is that the brute force computer does not know abut the restriction. So they try all those keys you say are invalidated by the *internally* applied rule.. The hack computer has no knowledge of the requisite. So those keys you claim are now part of the invalid set are STILL in their compendium of "tries".
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-12 14:24 +0100 |
| Message-ID | <mvgc67$9kr$1@dont-email.me> |
| In reply to | #72608 |
On 12/10/15 13:54, DecadentLinuxUserNumeroUno wrote: > On Mon, 12 Oct 2015 09:01:24 +0100, Richard Heathfield <rjh@cpax.org.uk> > Gave us: > >> On 12/10/15 07:30, DecadentLinuxUserNumeroUno wrote: >>> On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> >>> Gave us: >>> >>>> Restrictions on allowable keys make brute force easier, not harder. >>> >>> No. It is harder because the set of possible keys is larger, and >>> brute force means each one is attempted whole. >> >> Let us consider, at the risk of confusing you even more, a five-bit >> password. We have two sites, one which accepts *any* five-bit password, >> and one that requires you to have at least two clear bits and at least >> two set bits. >> >> Site A - all 5-bit passwords are acceptable >> 00000 00001 00010 00011 00100 00101 00110 00111 >> 01000 01001 01010 01011 01100 01101 01110 01111 >> 10000 10001 10010 10011 10100 10101 10110 10111 >> 11000 11001 11010 11011 11100 11101 11110 11111 >> >> 32 possible passwords. Worst case brute force: 32 guesses. Mean: 16. >> >> Site B - 5-bit passwords must have at least two clear and two set bits. >> xxxxx xxxxx xxxxx 00011 xxxxx 00101 00110 00111 >> xxxxx 01001 01010 01011 01100 01101 01110 xxxxx >> xxxxx 10001 10010 10011 10100 10101 10110 xxxxx >> 11000 11001 11010 xxxxx 11100 xxxxx xxxxx xxxxx >> >> By restricting the kinds of passwords available to the user, we now have >> only 20 possible passwords. Worst case brute force: 20 guesses. Mean: 10. >> >> Restrictions decrease the amount of work required for brute force. > > The mistake you are making is that the brute force computer does not > know abut the restriction. Of course it does! That's public knowledge. Otherwise, how do you tell your users what they're allowed to type? Kerckhoffs's Principle requires that we assume the adversary has full knowledge of the algorithm. So yes, the brute force computer *does* know about the restriction, and can code around it. > So they try all those keys you say are > invalidated by the *internally* applied rule.. Clearly not. That would be a stupid thing to do. Never assume your adversary is stupid. A brute force attack tries all the keys (until it finds the right one). It is under no obligation to try things that are not keys. > The hack computer has no knowledge of the requisite. Wrong, unless the cracker is an idiot. Brute force search tries all legal keys, but is under no obligation to try illegal keys. > So those keys you claim are now part of the > invalid set are STILL in their compendium of "tries". Wrong. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-12 07:07 -0700 |
| Message-ID | <a8a471a7-6a5d-455e-989f-871c3d3e2b5f@googlegroups.com> |
| In reply to | #72612 |
On Monday, October 12, 2015 at 2:24:32 PM UTC+1, Richard Heathfield wrote: > > Clearly not. That would be a stupid thing to do. Never assume your > adversary is stupid. > Don't design you strategy so it fails catastrophically if the adversary is not stupid. But often you can exploit stupid people. For example some people offer racing tips. It's a sure fire offer, if the tipped horse doesn't win, you get your money back. Can't lose, right?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-12 13:02 -0400 |
| Message-ID | <mvgova$vej$1@dont-email.me> |
| In reply to | #72608 |
On 10/12/2015 08:54 AM, DecadentLinuxUserNumeroUno wrote: > On Mon, 12 Oct 2015 09:01:24 +0100, Richard Heathfield <rjh@cpax.org.uk> ... >> Restrictions decrease the amount of work required for brute force. > > The mistake you are making is that the brute force computer does not > know abut the restriction. Why not? The overwhelming majority of the hundreds of passwords I currently maintain give access to public web sites that anyone with internet access can register at, and where the registration process lets you know what the restrictions on passwords are - and it lets you know that before you've even completed registration. Many of those passwords give you access to all of the funds I have stored in various financial institutions, so I consider them pretty important. On some systems, you can't find out the password restrictions until after you've given them a valid account number that you got by opening the financial account in the first place. However, that could be a stolen account number, and legitimately opening one real account at an institution, in order to get the information you need to break into all of the other accounts at that institution seems a small price to pay. For workplace passwords, including government computers, all it takes is one dissaffected worker (or, with social engineering, one stupid worker) to find out what the restrictions are. "Hello, this is the IT security department - we wanted to make sure that your password meets all of the restrictions we've imposed - do you know what those restrictions are?" People have used such methods to get actual passwords, getting the password restrictions can't be any harder than that. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-12 15:24 +0000 |
| Message-ID | <mvgjak$7r4$1@dont-email.me> |
| In reply to | #72583 |
In sci.crypt DecadentLinuxUserNumeroUno <DLU1@decadentlinuxuser.org> wrote: > On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> > Gave us: > >Restrictions on allowable keys make brute force easier, not harder. > No. It is harder because the set of possible keys is larger, and > brute force means each one is attempted whole. The 'set of possible keys' is only larger if you assume that 'no restrictions' means that a human will pick a poor password at the outset. Which, sadly, is true for humans doing the choosing. But any restriction on what characters 'must' appear does reduce the possible brute force search space from 'all possible characters anywhere' (which is what "no restrictions" means) to some smaller subset which fits the pattern of the restriction. Another analogy to see if you will finally understand what Richard H. has been trying to explain. Password A requires: pick 8 bytes Password B requires: pick 8 bytes, but you must use at least eight numerical digits Password A is where Richard H. is arguing from, it has "no restrictions" which means all 8 bytes can contain a value from ASCII null (0x00) to a byte 0xff. 256 different byte values, times eight different positions. Or 256^8 possible combinations, from bc: 256^8 18,446,744,073,709,551,616 That is a really big number. Now, password B says "8 bytes" but "restricts" the values of those eight bytes to numerical digits. There are only ten numerical digits. So the total combinations are 10^8 (from bc, although I would not have to use bc for this) is: 10^8 100,000,000 The restriction does reduce the total possible combinations. The 'increase' you keep arguing about is because it forces a human to pick from a larger possible set of characters, but that is only an 'increase' given that typical humans pick from very restricted sets of characters if not forced to do otherwise.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-12 00:18 -0400 |
| Message-ID | <mvfc65$5ke$1@dont-email.me> |
| In reply to | #72560 |
On 10/11/2015 10:59 PM, Richard Heathfield wrote: > On 12/10/15 01:51, James Kuyper wrote: >> On 10/11/2015 02:55 PM, Richard Heathfield wrote: >>> On 11/10/15 18:13, DecadentLinuxUserNumeroUno wrote: ... >>>> It doesn't matter, idiot. It still foils brute force search hacking >>>> better. > > This is the key line that everyone seems to be ignoring, but which is > the line to which I was actually responding. I'm afraid I paid more attention to your carefully reasoned response than to the rant that provoked it. Sorry! >>> Assume an 8-character password, with legal characters [A-Z][a-z][0-9]. >>> There are 218340105584896 such passwords, but 53459728531456 of them >>> have no digits. Thus, even ignoring the upper/lower case rule, an >>> adversary can eliminate almost a quarter of the search space (24.48+%). >>> Even with 15-character passwords, around 7% of the search space can be >>> ignored. And that's not even including the lower/upper case rule. >>> >>> Could you please explain how "having fewer candidate keys to test" is >>> harder than "having more candidate keys to test"? >> >> It involves human psychology > > James, the context is brute force, not a dictionary attack. So human > psychology doesn't come into it. What comes into it is "number of > permutations". Only. True - it's the dictionary attack that those rules are intended to make more difficult; they actually make the brute force attack marginally less inefficient. Personally, I think it makes more sense to be worried about dictionary attacks, they can catch a lot of low-hanging fruit very quickly. A couple of years ago, the annual security training that our client requires us to take mentioned that 12 character passwords were, at that time, barely long enough to provide adequate protection against brute force attack, which is why our policies were changed to require a minimum of 12 characters. I haven't seen updated advice about that issue, I imagine the minimum is larger now - but I haven't seen a change to our policies - possibly due to increased reliance on VPNs and biometric security methods. That doesn't help at all with any of my hundreds of passwords that aren't work related. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-16 16:31 -0500 |
| Message-ID | <d8d8ksFrifjU1@mid.individual.net> |
| In reply to | #72560 |
On 2015-10-12 02:59:16 +0000, Richard Heathfield said: > On 12/10/15 01:51, James Kuyper wrote: >> On 10/11/2015 02:55 PM, Richard Heathfield wrote: >>> On 11/10/15 18:13, DecadentLinuxUserNumeroUno wrote: >>>> On Sun, 11 Oct 2015 19:03:56 +0200, "Skybuck Flying" >>>> <skybuck2000@hotmail.com> Gave us: >>>> >>>>> Oh and by the way... >>>>> >>>>> The intel community website... has the most annoying password requirements >>>>> ever !!! >>>> >>>> You're a goddamned idiot, child. >>>>> >>>>> It must be 8 to 15 characters.. >>>>> must contain lower and upper and a fokking digit or something and/or a >>>>> special character ?! >>>>> >>>>> wtf ?! >>>> >>>> And now you show just how stupid you really are as it relates to >>>> secure login crypto. More folks use the site for real business purpose, >>>> and only childish idiots like you are too stupid to know what is going >>>> on. >>>>> >>>>> This will not make it more secure at all... because people will probably put >>>>> the special requirements at the back ! >>>> >>>> It doesn't matter, idiot. It still foils brute force search hacking >>>> better. > > This is the key line that everyone seems to be ignoring, but which is > the line to which I was actually responding. > >>> >>> Assume an 8-character password, with legal characters [A-Z][a-z][0-9]. >>> There are 218340105584896 such passwords, but 53459728531456 of them >>> have no digits. Thus, even ignoring the upper/lower case rule, an >>> adversary can eliminate almost a quarter of the search space (24.48+%). >>> Even with 15-character passwords, around 7% of the search space can be >>> ignored. And that's not even including the lower/upper case rule. >>> >>> Could you please explain how "having fewer candidate keys to test" is >>> harder than "having more candidate keys to test"? >> >> It involves human psychology > > James, the context is brute force, not a dictionary attack. So human > psychology doesn't come into it. What comes into it is "number of > permutations". Only. That may be the context of your attempts to teach DecadentLinuxUserNumeroUno math, but it is not the appropriate context for discussing whether these password restrictions are a good thing or a bad thing. A number of people here think that those who crack passwords only do 1. Brute force attack 2. Dictionary attack But that simply isn't true. Unless the password space is particularly small, nobody does a brute force attack. And a dictionary attack is only the first quick phase of a real attack. Password cracking systems typically make use of one of two kinds of approaches 1. Generative rules of regexes followed by transformations 2. Markov models It should be noted that in both of those they generate guesses that are not from some dictionary, but these aren't brute force attacks either. So, in many cases, those systems are the threat. Brute force is not the threat. So the challenge is to find a way to get people to use passwords that can stand up to such attacks. And we must do so with the understanding that if we ask people to do things that are humanly impossible or particularly burdensome, they won't do it. These password restrictions are an attempt at that. A very flawed attempt, which can often be counter-productive; but still it is an attempt at addressing a very real problem. And whatever one tries to do to address this problem, human psychology is going to be central to the design. So sure, DecadentLinuxUserNumeroUno, is spectacularly wrong about the math; but given that brute force attacks are not the actual threat that passwords face, the conversation has moved beyond those math problems. Cheers, -j
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-16 15:55 -0500 |
| Message-ID | <d8d6isFr1seU1@mid.individual.net> |
| In reply to | #72540 |
On 2015-10-12 00:51:04 +0000, James Kuyper said: > It involves human psychology - when you don't impose limits on > passwords, people disproportionately likely to choose them from a very > small subset of that larger set Thank you. Yes. The design goal of these sorts of requirements wasn't to increase the set of possible passwords (as we know, it does the opposite); instead it was to "trick" people into picking better passwords than the would have without such requirements. Now it is debatable about whether that effort succeeded even then, but we know that people cracking passwords know how people respond to the sorts of requirements they are presented with. So even if these were once a reasonable approach, we need to find a better way to do this. There is a lot of research on this, some of the best is coming out of the Usable Security Group at CMU. One recent project to come out of there actually talks about how all of these requirements have ended teaching people some very incorrect things about password security. http://www.blaseur.com/papers/soups15-paper-ur.pdf Title: “I Added ‘!’ at the End to Make It Secure”: Observing Password Creation in the Lab And as we've seen in this discussion, some people who really should know better, get the math backwards and seem to think that the requirements add to the potential search space (without considering human choice). So although there is a reason for these sorts of requirements, what I've seen in this discussion is that few people from either side understand what the original design goals were. How successful these are at meeting their design goals is a different question. Actual password behavior is a hard thing to get good data on, but there is some. When it comes to password policies in an organization some of our best data comes from consultants brought in to study (i.e, crack) passwords and who are given permission to talk about what they find. > - and the hackers have, through lots of > experience, successfully characterized that small subset, and have > routines tha t make searching it very efficient.. Yep. This is also a situation in which the bad guys have must more data on password behavior than the good guys. > When you do impose > such limits on passwords, you force people somewhat out of their usual > patterns, and they'll end up choosing a password from a portion of the > smaller set which is much larger than the portion they use when there > are no limits, and that larger portions is not as well characterized by > the hackers. That is the idea. But the password crackers also know how people behave in response to these password requirements. Consider that it is "At least one digit and one upper case letter, and more than 8 characters" that made "Password1" the most popular password. So while I understand the design goals of these sorts of requirements, they at best provide a momentary gain, but in general they make people's behavior even more predictable. > I use randomly generated passwords; Good for you! > they're harder to memorize, but it > only takes me a week or so to memorize the ones I use daily. The ones I > use less frequently are stored in an encrypted file stored using an app > on my smart phone that has no permissions to access any of the external > connections of my phone. Good. [Disclosure: I work for AgileBits, the makers of 1Password, a password manager.] Cheers, -j
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-16 17:33 -0400 |
| Message-ID | <mvrqc2$t0q$1@dont-email.me> |
| In reply to | #73076 |
On 10/16/2015 04:55 PM, Jeffrey Goldberg wrote: > On 2015-10-12 00:51:04 +0000, James Kuyper said: ... >> I use randomly generated passwords; > > Good for you! > >> they're harder to memorize, but it >> only takes me a week or so to memorize the ones I use daily. The ones I >> use less frequently are stored in an encrypted file stored using an app >> on my smart phone that has no permissions to access any of the external >> connections of my phone. > > Good. > > [Disclosure: I work for AgileBits, the makers of 1Password, a password > manager.] Perhaps you could address an issue that bothered me. How can I trust the maker of my password manager? That's one reason why I chose a manager that doesn't need any external connections - I feel safer if the information is stored only on my smartphone, and not in some central repository. However, it seems to me that the password manager could choose an encryption scheme that would allow it's maker to access my information even without the password that I have to use to access that same data. Even if my password manager itself cannot connect to the outside world, another app that did have that ability might given them access to my file. As a simple practical matter of fact, I've chosen to trust the maker of my password manager - but only because I didn't have a workable alternative. Maintaining a small number of passwords for a large number of different accounts is a bad idea, choosing passwords that are easy to remember also makes them easy to crack, and keeping track of large numbers of random passwords was just getting too difficult to do by any other method. However, I don't have any information to justify the trust I'm giving that company. I know nothing of it's reputation. I haven't seen any password manager that was made by any company I'd ever heard of before I started looking for password managers. At a NASA IT security briefing, 1Password was the only password manager mentioned by name, but they went out of their way to say that they were NOT endorsing it. In fact, while they said it was OK for us to use a password manager for other passwords, we were prohibited from using one for our NASA passwords - which is actually a kind of negative endorsement for the whole idea. Can you comment, preferably in an official capacity as a representative of your company, but if you company policy prohibits that, could you at least give us an unofficial personal response? -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-17 01:32 +0000 |
| Message-ID | <mvs8fo$7l5$1@dont-email.me> |
| In reply to | #73089 |
In sci.crypt James Kuyper <jameskuyper@verizon.net> wrote: > On 10/16/2015 04:55 PM, Jeffrey Goldberg wrote: > > [Disclosure: I work for AgileBits, the makers of 1Password, a > > password manager.] > Perhaps you could address an issue that bothered me. How can I trust > the maker of my password manager? That's one reason why I chose a > manager that doesn't need any external connections - I feel safer if > the information is stored only on my smartphone, and not in some > central repository. One way is to choose a password manager that is free software/open source, such that you get to view the source and compile (if needed) the object file you utilize yourself. Choosing one that requires no external servers means you do not have to worry about the external servers being compromised, which is also a good thing. > However, it seems to me that the password manager could choose an > encryption scheme that would allow it's maker to access my > information even without the password that I have to use to access > that same data. Yep, entirely possible, and if you do not have access to the source then you have to either blindly trust that they will not do this, or try to dig the answer out of the compiled object code (a much harder task than from the source level).
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-17 01:12 -0400 |
| Message-ID | <m0m32blkthjkkcfh4rvi890288uq16e58j@4ax.com> |
| In reply to | #73123 |
On Sat, 17 Oct 2015 01:32:40 +0000 (UTC), Rich <rich@example.invalid> Gave us: >In sci.crypt James Kuyper <jameskuyper@verizon.net> wrote: >> On 10/16/2015 04:55 PM, Jeffrey Goldberg wrote: >> > [Disclosure: I work for AgileBits, the makers of 1Password, a >> > password manager.] > >> Perhaps you could address an issue that bothered me. How can I trust >> the maker of my password manager? That's one reason why I chose a >> manager that doesn't need any external connections - I feel safer if >> the information is stored only on my smartphone, and not in some >> central repository. > >One way is to choose a password manager that is free software/open >source, such that you get to view the source and compile (if needed) >the object file you utilize yourself. > >Choosing one that requires no external servers means you do not have to >worry about the external servers being compromised, which is also a >good thing. > >> However, it seems to me that the password manager could choose an >> encryption scheme that would allow it's maker to access my >> information even without the password that I have to use to access >> that same data. > >Yep, entirely possible, and if you do not have access to the source >then you have to either blindly trust that they will not do this, or >try to dig the answer out of the compiled object code (a much harder >task than from the source level). Password managers only work for online web sites. They are worthless when you are logging on your just booted machine. Our machines also timeout and log off if you walk away and leave it unattended. They do nothing in those cases either.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-17 12:53 -0400 |
| Message-ID | <56227CF4.8050501@verizon.net> |
| In reply to | #73139 |
On 10/17/2015 01:12 AM, DecadentLinuxUserNumeroUno wrote: ... > Password managers only work for online web sites. They are worthless > when you are logging on your just booted machine. I currently use mine to store seven passwords that could be used to log into any one of three different just-booted machines. I also use it for the PINS to my debit cards, two different voice mail systems, and my garage door, as well as the passwords required by several of the apps on my smartphone, one password I need to open a window on an Windows system from my Linux workstation, and the passwords I need to access three different Wifi systems. None of those are online web sites. So, the seeming usefulness of those things must be a misunderstanding on my part - could you tell me what that is that I'm misunderstanding?
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-17 19:32 -0400 |
| Message-ID | <gem52bhhlnujucsh2gfdd79dfr3607192d@4ax.com> |
| In reply to | #73150 |
On Sat, 17 Oct 2015 12:53:08 -0400, James Kuyper <jameskuyper@verizon.net> Gave us: >On 10/17/2015 01:12 AM, DecadentLinuxUserNumeroUno wrote: >... >> Password managers only work for online web sites. They are worthless >> when you are logging on your just booted machine. > >I currently use mine to store seven passwords that could be used to log >into any one of three different just-booted machines. How does it work for a just booted machine? Does it auto-fill the login name and password? If it auto-fills anything, it would not only be against policy at my company, but it would also violate law. As a related question, do you think Hillary should be jailed for her felonious behavior? >. I also use it for >the PINS to my debit cards, If you cannot remember those, you shouldn't be carrying any. >two different voice mail systems, and my >garage door, as well as the passwords required by several of the apps on >my smartphone, one password I need to open a window on an Windows system >from my Linux workstation, and the passwords I need to access three >different Wifi systems. None of those are online web sites. So, the >seeming usefulness of those things must be a misunderstanding on my part > - could you tell me what that is that I'm misunderstanding? I obviously must not know how these work, but they seem to be a huge vulnerability.
[toc] | [prev] | [next] | [standalone]
| From | Chad <cdalten@gmail.com> |
|---|---|
| Date | 2015-10-17 20:29 -0700 |
| Message-ID | <7eaafba2-5d47-41fe-986f-7bed2c0d90fe@googlegroups.com> |
| In reply to | #73172 |
This is truly the most out of control thread that I've read in a while.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-10-18 08:10 +0000 |
| Message-ID | <mvvk65$f5$1@news.xmission.com> |
| In reply to | #73184 |
In article <7eaafba2-5d47-41fe-986f-7bed2c0d90fe@googlegroups.com>,
Chad <cdalten@gmail.com> wrote:
>This is truly the most out of control thread that I've read in a while.
Indeed. Simply amazing.
One really wonders why Leader Kiki hasn't come in and shut this whole
thing down. Surely, that is what we expect from the recognized forum
admin.
--
"If God wanted us to believe in him, he'd exist."
(Linda Smith on "10 Funniest Londoners", TimeOut, 23rd June, 2005.)
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-18 11:08 -0500 |
| Message-ID | <d8huflF35cuU1@mid.individual.net> |
| In reply to | #73172 |
On 2015-10-17 23:32:16 +0000, DecadentLinuxUserNumeroUno said: > On Sat, 17 Oct 2015 12:53:08 -0400, James Kuyper > <jameskuyper@verizon.net> Gave us: > >> On 10/17/2015 01:12 AM, DecadentLinuxUserNumeroUno wrote: >> ... >>> Password managers only work for online web sites. They are worthless >>> when you are logging on your just booted machine. >> >> I currently use mine to store seven passwords that could be used to log >> into any one of three different just-booted machines. > > How does it work for a just booted machine? Does it auto-fill the > login name and password? I don't want to speak for James K., but I will answer for myself. I read the passwords from my phone and type them into the just booted computer. Note that when generatoring passwords that you expect to transcribe this way, it is good to use generation rules that create passwords that are reasonably easy to transcribe. You seem to be assuming that password managers only work by autofilling. > If it auto-fills anything, it would not only be against policy at my > company, but it would also violate law. What law is that? Cheers, -j
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-18 17:15 -0400 |
| Message-ID | <nt282b5v6eklubur2tpr43g5ug90kcmged@4ax.com> |
| In reply to | #73210 |
On Sun, 18 Oct 2015 11:08:21 -0500, Jeffrey Goldberg <nobody@goldmark.org> Gave us: >> If it auto-fills anything, it would not only be against policy at my >> company, but it would also violate law. > >What law is that? > >Cheers, > >-j Storage device holding classified information or information which allows access to classified information. And yes, your phone IS a storage device.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-18 12:42 -0400 |
| Message-ID | <5623CBDA.70403@verizon.net> |
| In reply to | #73172 |
On 2015-10-17 23:32:16 +0000, DecadentLinuxUserNumeroUno said: > On Sat, 17 Oct 2015 12:53:08 -0400, James Kuyper > <james...@verizon.net> Gave us: > >>On 10/17/2015 01:12 AM, DecadentLinuxUserNumeroUno wrote: >>... >>> Password managers only work for online web sites. They are worthless >>> when you are logging on your just booted machine. >> >>I currently use mine to store seven passwords that could be used to log >>into any one of three different just-booted machines. > > How does it work for a just booted machine? Does it auto-fill the > login name and password? No, it shows me the login name and the password, and then I type it in. It's certainly easier to use when launching web sites, where it does fill in the password for me, but it's still more convenient than any other method I'm familiar with for keeping track of a large number of random passwords for non-web sites.
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| Date | 2015-10-17 10:01 +0200 |
| Message-ID | <a9dd5$56220052$d47876e2$19527@news.ziggo.nl> |
| In reply to | #73089 |
"James Kuyper" wrote in message news:mvrqc2$t0q$1@dont-email.me... On 10/16/2015 04:55 PM, Jeffrey Goldberg wrote: > On 2015-10-12 00:51:04 +0000, James Kuyper said: ... >> I use randomly generated passwords; > > Good for you! > >> they're harder to memorize, but it >> only takes me a week or so to memorize the ones I use daily. The ones I >> use less frequently are stored in an encrypted file stored using an app >> on my smart phone that has no permissions to access any of the external >> connections of my phone. > > Good. > > [Disclosure: I work for AgileBits, the makers of 1Password, a password > manager.] " I feel safer if the information is stored only on my smartphone " Well, that's fucked ! LOLOLOLOL. <snip> rest don't matter if you store it there ! LOL. Bye, Skylol =D
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-18 00:34 -0500 |
| Subject | Trusting password managers [Re: Firefox improvements.] |
| Message-ID | <d8gpbbFodfuU1@mid.individual.net> |
| In reply to | #73089 |
On 2015-10-16 21:33:52 +0000, James Kuyper said: > On 10/16/2015 04:55 PM, Jeffrey Goldberg wrote: >> On 2015-10-12 00:51:04 +0000, James Kuyper said: > ... >>> I use randomly generated passwords; >> >> Good for you! >> >>> they're harder to memorize, but it >>> only takes me a week or so to memorize the ones I use daily. The ones I >>> use less frequently are stored in an encrypted file stored using an app >>> on my smart phone that has no permissions to access any of the external >>> connections of my phone. >> >> Good. >> >> [Disclosure: I work for AgileBits, the makers of 1Password, a password >> manager.] > > Perhaps you could address an issue that bothered me. How can I trust the > maker of my password manager? The short answer is for me to point you to a longer answer https://blog.agilebits.com/2013/09/06/1password-and-the-crypto-wars/ ## Starting with the bad news Let me start out by pointing out that we are not an open source, and in the absense of deterministic builts, even publishing the source couldn't give you perfect assurance either. You would need some way to know that the binary you are running was built from the reviewed source and that it was built with trusted tools. (The old idea of an evil compiler has been shown to exist in practice with XcodeGhost.) So there is a certain level of assurance that we can't provide. We are good guys, but we can't prove that we are to such a level of certainty. But if you are willing to look at things that fall short of absolute proof there are a number of things. ## Verifiable claims (Almost) all of our claims about security and privacy are verifiable. You can look at the data and you can look at our specification of the data form and see that, yes, things are encrypted as we say they are. You can monitor your own network traffic and verify that it behaves as we say it does. First there are the purely technical ones. Where are keys generated, how are keys generated, where is all encryption done, what if anything is passed to something out of your own control. With 1Password, we've picked a design (which you can largely verify) that has all keys generated locally and all encryption done locally. Quite simply, 1Password uses end-to-end encryption. We've also designed things so that we know pretty much nothing about our customers. We might have purchase records, and records if you contact us, but your use of 1Password does not involve (much) interaction with us. For details (and an explanation of that "much") see https://support.1password.com/private-by-design/ Our view is that we cannot lose, use, or abuse data we never have. So best is to never have it and to do what we can to make it hard for us to acquire it. Again pretty much everything we say can be verified by you. ### Example of this design approach Let me give you an example. Shortly after heartbleed we introduced a feature, "Watchtower" that lets you know whether you have login credentials for sites on which we recommend a password change. The easiest way to implement this in the application would be for it to contact some service that we would run and query about specific logins. But that design would mean that our service would know which sites you have logins for. We don't want to know whether you have Pintrest login and how often you use it. So instead we designed it so that the application simply fetched our database about which sites suffered breaches when. The querying of that database is done locally on your device, and we are never in a position to learn what sites you have logins for. ## Simply business When I joined AgileBits, there were less than a dozen people. Now we have more than 60. Most are full time. This is a lot of people whose livelihoods depend on maintaining your trust. Over even a relatively short term, we make more money selling you software than we could by stealing your passwords. ### Competence It is remarkably easy to write a bad password manager, even with the best intentions and access to good cryptographic libaries. I think we have a fairly deep understanding of the tools that we use and so are far less likely to use them wrong. We understand the choice of encryption modes beyond whether you end up seeing penguins. Obviously it would be ridiculous to claim that we are bug-free or even that our design is provably secure. (Complexities, mostly having to do with data synchronization, make the design go beyond what we can comfortably prove theorems about.) But we can use a kind of defense in depth in both our coding and our design. That is, if something that we believe is secure should fail, to what extent would that lead to a catestrophic failure or would the damage be contained by other aspects of the design and coding. ### Coercion The story of Lavabit scares me. And it is one of the reaons why we like to have nothing of value that we could turn over. Again, we've tried to design things so that not only is there no back door, it would be tricky to put in a backdoor (without getting spotted doing so). > That's one reason why I chose a manager > that doesn't need any external connections - I feel safer if the > information is stored only on my smartphone, That makes synchronization across devices tricky. We are sort of half way in between. We don't host your data, but we do set things up to make third party sync services work for you. But again, we use end-to-end authenticated encryption so, if we've done everything right, the worst that could happen with a server compromise is that synching would stop working. > However, it seems to me that the password manager could > choose an encryption scheme that would allow it's maker to access my > information even without the password that I have to use to access that > same data. Again, we fully detail our encryption scheme and it is possible for you to verify that things are encrypted as we say. Now, again, this doesnt' 100% rule out all attacks. For example, if we were to corrupt the RNG that is used for generating keys, it would be possible for encrypt as we say we do, but with giving us an advantage in cracking. Your only full defense against this is a reviewed, open-source solution, which you compile yourself using a compiler that you also can fully trust and running on an operating system that you can fully trust. However, we can offer a partial defense. There are a couple of dozen people who have eyes on the source. It would just take one to spot something like that and go public to completely destroy us if any such malicious mechanism were in place. So this doesn't completely rule out something of that nature, it does reduce the chance of getting away with some malicious mechanism. > As a simple practical matter of fact, I've chosen to trust the maker of > my password manager - but only because I didn't have a workable > alternative. Maintaining a small number of passwords for a large number > of different accounts is a bad idea, Yep. Password reuse is probably a bigger problem than weak passwords. > choosing passwords that are easy to > remember also makes them easy to crack, and keeping track of large > numbers of random passwords was just getting too difficult to do by any > other method. We have to make choices. In a sense, many of the choices that we make aren't "security versus convenience" but instead is one type of security versus another. > However, I don't have any information to justify the trust I'm giving > that company. Please follow the links above for information about us. > At a NASA IT security briefing, > 1Password was the only password manager mentioned by name, but they went > out of their way to say that they were NOT endorsing it. In fact, while > they said it was OK for us to use a password manager for other > passwords, we were prohibited from using one for our NASA passwords - > which is actually a kind of negative endorsement for the whole idea. Under the law, NASA aren't allowed to use a password manager for their passwords. I can't speak for them, but I think that what you encountered was the strongest endorsement they could possibly offer. > Can you comment, preferably in an official capacity as a representative > of your company, but if you company policy prohibits that, could you at > least give us an unofficial personal response? Pretty much everything I've said here is on our site somewhere; but other than lack of proper proof reading and such, I'm guess I can consider this "official-ish". Cheers, -j –- Jeffrey Goldberg Chief Defender Against the Dark Arts @ AgileBits http://agilebits.com
[toc] | [prev] | [next] | [standalone]
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web