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 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-15 12:16 -0400 |
| Message-ID | <47kv1b1eq848lcaqlsi4u15lccbq1494s4@4ax.com> |
| In reply to | #72919 |
On Wed, 14 Oct 2015 22:31:54 -0400, DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote: >On Wed, 14 Oct 2015 22:24:22 -0400, krw <krw@nowhere.com> Gave us: > >>On Wed, 14 Oct 2015 21:10:42 -0400, DecadentLinuxUserNumeroUno >><DLU1@DecadentLinuxUser.org> wrote: >> >>>On Wed, 14 Oct 2015 20:39:07 -0400, krw <krw@nowhere.com> Gave us: >>> >>>>How do you choose a password if you don't know the rules? Choose, get >>>>rejected, chose another, rinse... >>> >>> The *public* does not know the rules. Those within the establishment >>>do. >> >>That's absurd. How secure is that? Hundreds (of thousands?) know the >>rules but you expect it somehow to be a secret? Silly. >> > As stated earlier. I refer to my company. The rules are NOT public. >Learn to read. It isn't a website access. It doesn't matter what it is. Keeping algorithms secret is folly. Keeping password rules secret is even dumber. > So re-read it, dumbass. Only a dumbass would agree that obscurity gives any real security. It surely seems to apply to you.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-15 16:25 -0400 |
| Message-ID | <5t202bteancugqh87pmohu5vaa24pfnbnv@4ax.com> |
| In reply to | #72959 |
On Thu, 15 Oct 2015 12:16:36 -0400, krw <krw@nowhere.com> Gave us: >On Wed, 14 Oct 2015 22:31:54 -0400, DecadentLinuxUserNumeroUno ><DLU1@DecadentLinuxUser.org> wrote: > >>On Wed, 14 Oct 2015 22:24:22 -0400, krw <krw@nowhere.com> Gave us: >> >>>On Wed, 14 Oct 2015 21:10:42 -0400, DecadentLinuxUserNumeroUno >>><DLU1@DecadentLinuxUser.org> wrote: >>> >>>>On Wed, 14 Oct 2015 20:39:07 -0400, krw <krw@nowhere.com> Gave us: >>>> >>>>>How do you choose a password if you don't know the rules? Choose, get >>>>>rejected, chose another, rinse... >>>> >>>> The *public* does not know the rules. Those within the establishment >>>>do. >>> >>>That's absurd. How secure is that? Hundreds (of thousands?) know the >>>rules but you expect it somehow to be a secret? Silly. >>> >> As stated earlier. I refer to my company. The rules are NOT public. >>Learn to read. It isn't a website access. > >It doesn't matter what it is. Keeping algorithms secret is folly. >Keeping password rules secret is even dumber. > >> So re-read it, dumbass. > >Only a dumbass would agree that obscurity gives any real security. It >surely seems to apply to you. It worked for Lincoln.
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| Date | 2015-10-21 08:03 +0200 |
| Message-ID | <a5946$56272a9f$d47876e2$51972@news.ziggo.nl> |
| In reply to | #72959 |
" It doesn't matter what it is. Keeping algorithms secret is folly. Keeping password rules secret is even dumber. " > So re-read it, dumbass. " Only a dumbass would agree that obscurity gives any real security. It surely seems to apply to you. " I am not so sure about that "*motherfokker*". You assume that if something is only obscure that it will eventually be understood. However there is a *slight* problem with that assumption. What if the *understanding process* of the obscurity takes so long that a human being cannot do it within reasonable time ?! Does this make the obscurity just as good as encryption ? I would say so... cause encryption is then also a form of obscurity to some degree. Though there are always those that same that different plain texts might occur... I'd like to see a bi tmore prove of that before I buy that. Though my posting is not to call encryption "obscurity" because encryption might be a little bit more than that in case the number of possible plain text is indeed large. However my posting is to point out that if the understanding process of the obscurity is not automated then the obscurity will hold for a long time. And thus it is your job to *automate* the understanding process of the obscurity. Just *automating the understanding process of the obscurity* can already be quite an undertaking. One nice example of this is ofcourse the well known "disassembler dream" of disassmblieing x86 into perfectly really pseudo code. Such a thing does not really exist... there are some disassemblers... but for now none of them can re-create the perfect pseudo code or even an pseudo code that might make it more easy to understand... even if it did you will still need plenty of time to understand the pseudo code. Having said that there are definetly systems thinkeable/possibly where you would have to proof... that the obscurity can be undone... before you can actually claim that the obscurity would not work. And you would have to proof that in reasonable time. So the premise I guess is that "security through obscurity" can provide "security for a long enough time" after that time the security will have to be replaced. And this is basically what KEY LENGTH is all about... the KEY has to be long enough for "brute force attack" to fail/be impossible in reasonable time. Now I will let it be to you, to explain again... why OBSCURITY is not security "for the time being" ?! HAHA ! :P Yes eventually it might/will be broken... but not for now ! ;) :P* Bye, Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-14 22:50 -0400 |
| Message-ID | <mvn456$rqn$1@dont-email.me> |
| In reply to | #72916 |
On 10/14/2015 10:24 PM, krw wrote: > On Wed, 14 Oct 2015 21:10:42 -0400, DecadentLinuxUserNumeroUno > <DLU1@DecadentLinuxUser.org> wrote: > >> On Wed, 14 Oct 2015 20:39:07 -0400, krw <krw@nowhere.com> Gave us: >> >>> How do you choose a password if you don't know the rules? Choose, get >>> rejected, chose another, rinse... >> >> The *public* does not know the rules. Those within the establishment >> do. > > That's absurd. How secure is that? Hundreds (of thousands?) know the > rules but you expect it somehow to be a secret? Silly. He's talking about a computer accounts that he has access to because of where he works. The biggest company I ever worked for had 80,000 workers, and because it was so big, it had lots of semi-independent sub-divisions. I'm not sure that the password restrictions on my company account applied to more than a small fraction of that population. My current employer qualifies for a small-business set-aside contract, so it's much smaller than that, a few thousand people at most. That's still too many people to be guaranteed to keep a secret, but it's much smaller than the numbers you're talking about. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-15 12:19 -0400 |
| Message-ID | <tbkv1bhtsmvd20s7p6coti3p54te8aka0j@4ax.com> |
| In reply to | #72922 |
On Wed, 14 Oct 2015 22:50:11 -0400, James Kuyper <jameskuyper@verizon.net> wrote: >On 10/14/2015 10:24 PM, krw wrote: >> On Wed, 14 Oct 2015 21:10:42 -0400, DecadentLinuxUserNumeroUno >> <DLU1@DecadentLinuxUser.org> wrote: >> >>> On Wed, 14 Oct 2015 20:39:07 -0400, krw <krw@nowhere.com> Gave us: >>> >>>> How do you choose a password if you don't know the rules? Choose, get >>>> rejected, chose another, rinse... >>> >>> The *public* does not know the rules. Those within the establishment >>> do. >> >> That's absurd. How secure is that? Hundreds (of thousands?) know the >> rules but you expect it somehow to be a secret? Silly. > >He's talking about a computer accounts that he has access to because of >where he works. The biggest company I ever worked for had 80,000 >workers, and because it was so big, it had lots of semi-independent >sub-divisions. I'm not sure that the password restrictions on my company >account applied to more than a small fraction of that population. My >current employer qualifies for a small-business set-aside contract, so >it's much smaller than that, a few thousand people at most. OK, who is the password trying to protect against? Does keeping the rules secret do anything to prevent hacking the system? If the system can only be accessed by trusted people, why keep silly things secret? > >That's still too many people to be guaranteed to keep a secret, but it's >much smaller than the numbers you're talking about. Hundreds? The point is that obscurity isn't security.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-14 22:26 -0400 |
| Message-ID | <mvn2oq$ohm$1@dont-email.me> |
| In reply to | #72900 |
On 10/14/2015 08:39 PM, krw wrote: > On Tue, 13 Oct 2015 23:10:29 -0400, DecadentLinuxUserNumeroUno > <DLU1@DecadentLinuxUser.org> wrote: ... >> It only makes it easier when those rules are known. >> >> I responded with my firm's not known rules in mind. You are correct >> about web sites with published password creation rules. > > How do you choose a password if you don't know the rules? Choose, get > rejected, chose another, rinse... Join company. Get investigated by the US government. Sit around for several weeks doing whatever you can that doesn't require access to the computer system (which, in our line of work, isn't very much). Get cleared by the US government . Get authorized to set up a computer account. Learn password restrictions. Set up computer account, which requires choosing your password. That's the way it works in my company. We're only a NASA contractor involved purely in the civilian side of NASA work. However, I have been authorized to enter various buildings that I need to enter to attend various meetings. Just a few rooms away from those meetings, are places I'm not allowed to enter because I don't have the required security clearance, so I can understand why the government wants to check up on me before giving me even that minimal level of access. Also, some of the data we work with is collected primarily for military purposes (weather forecasts over combat zones, for instance), and is only secondarily being put to civilian use (such as climate studies and agricultural forecasts). I can only imagine what it's like for workers on actual DoD or NSA contracts for the government. The key problem with the idea that your password restrictions are unknown to the enemy is that, no matter how good your security is, it takes only one disaffected worker for the details about the password rules to get leaked. Social engineering is also a good way to get a worker who is not disaffected, but merely naive, to give you the same information. We receive annual IT security training that's intended to make us not naive - but I'm positive that there are people who don't properly absorb the training information. Therefore, your security should not significantly depend upon the enemy not knowing those rules. Luckily, knowing those rules only give a rather small advantage. Actually following those rules gives a bigger advantage, though not against the kind of attacks that you consider to be brute force. Following those rules does give a big advantage against some of the attacks that Richard Heathfield considers to be brute force, because those "brute force" attacks use a lot of intelligence to target the most likely passwords first, and hit less likely passwords later. Knowing those rules allows such targeting to be slightly more accurate, but following those rules makes such targeting significantly harder, by a factor that more than makes up for the other effect. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-14 22:38 -0400 |
| Message-ID | <hd4u1bhoh1sf9hgt1mf1jk422d7jgkbm9q@4ax.com> |
| In reply to | #72918 |
On Wed, 14 Oct 2015 22:26:29 -0400, James Kuyper <jameskuyper@verizon.net> Gave us: >On 10/14/2015 08:39 PM, krw wrote: >> On Tue, 13 Oct 2015 23:10:29 -0400, DecadentLinuxUserNumeroUno >> <DLU1@DecadentLinuxUser.org> wrote: >... >>> It only makes it easier when those rules are known. >>> >>> I responded with my firm's not known rules in mind. You are correct >>> about web sites with published password creation rules. >> >> How do you choose a password if you don't know the rules? Choose, get >> rejected, chose another, rinse... > >Join company. Get investigated by the US government. Sit around for >several weeks doing whatever you can that doesn't require access to the >computer system (which, in our line of work, isn't very much). Get >cleared by the US government . Get authorized to set up a computer >account. Learn password restrictions. Set up computer account, which >requires choosing your password. > >That's the way it works in my company. We're only a NASA contractor >involved purely in the civilian side of NASA work. However, I have been >authorized to enter various buildings that I need to enter to attend >various meetings. Just a few rooms away from those meetings, are places >I'm not allowed to enter because I don't have the required security >clearance, so I can understand why the government wants to check up on >me before giving me even that minimal level of access. >Also, some of the data we work with is collected primarily for military >purposes (weather forecasts over combat zones, for instance), and is >only secondarily being put to civilian use (such as climate studies and >agricultural forecasts). > >I can only imagine what it's like for workers on actual DoD or NSA >contracts for the government. > >The key problem with the idea that your password restrictions are >unknown to the enemy is that, no matter how good your security is, it >takes only one disaffected worker for the details about the password >rules to get leaked. Social engineering is also a good way to get a >worker who is not disaffected, but merely naive, to give you the same >information. We receive annual IT security training that's intended to >make us not naive - but I'm positive that there are people who don't >properly absorb the training information. > >Therefore, your security should not significantly depend upon the enemy >not knowing those rules. Luckily, knowing those rules only give a rather >small advantage. Actually following those rules gives a bigger >advantage, though not against the kind of attacks that you consider to >be brute force. Following those rules does give a big advantage against >some of the attacks that Richard Heathfield considers to be brute force, >because those "brute force" attacks use a lot of intelligence to target >the most likely passwords first, and hit less likely passwords later. >Knowing those rules allows such targeting to be slightly more accurate, >but following those rules makes such targeting significantly harder, by >a factor that more than makes up for the other effect. Then, of course, the re-try, fail, get locked out mechanism gets implemented. Getting in without an actual known log-in name and password is *very* unlikely, if not truly impossible. We get the same seminars and we get ITAR seminars, and "don't plug in that USB flash drive" seminars, etc. And the user network segment is separated from the actual database network segment, and tunneling into them from an external terminal is as unlikely as it gets. About as likely that a PUF generator would generate a previously generated key. As in, as near zero as it gets.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-15 12:20 +0100 |
| Message-ID | <mvo21b$ic0$1@dont-email.me> |
| In reply to | #72921 |
On 15/10/15 03:38, DecadentLinuxUserNumeroUno wrote: > On Wed, 14 Oct 2015 22:26:29 -0400, James Kuyper > <jameskuyper@verizon.net> Gave us: <snip> >> Therefore, your security should not significantly depend upon the enemy >> not knowing those rules. Luckily, knowing those rules only give a rather >> small advantage. Actually following those rules gives a bigger >> advantage, though not against the kind of attacks that you consider to >> be brute force. Following those rules does give a big advantage against >> some of the attacks that Richard Heathfield considers to be brute force, >> because those "brute force" attacks use a lot of intelligence to target >> the most likely passwords first, and hit less likely passwords later. >> Knowing those rules allows such targeting to be slightly more accurate, >> but following those rules makes such targeting significantly harder, by >> a factor that more than makes up for the other effect. > > Then, of course, the re-try, fail, get locked out mechanism gets > implemented. For all you know, your adversary might be your Web site designer or your database administrator, who has been bribed to find out the CEO's password by someone who wishes to impersonate the CEO for fun and profit. Such an adversary will have access to the table that stores user names and hashes. So he finds an excuse to print that table, and takes it home. He knows the hashing algorithm, and he knows the end hash, so he can run a brute force attack *at home*, without having to try to log into the site *at all*, so the re-try, fail, get locked out mechanism doesn't apply. > Getting in without an actual known log-in name and password is *very* > unlikely, if not truly impossible. Except in cases where it isn't. In cryptology and authentication, the question is not whether you are being paranoid. It's whether you are being paranoid *enough*. <snip> -- 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 | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2015-10-13 22:54 -0500 |
| Message-ID | <d861v1F1te0U1@mid.individual.net> |
| In reply to | #72786 |
"Richard Heathfield" wrote: > Er, no. The original complaint was that the password restriction is > "annoying". In a reply to that complaint, the claim was made that the > restriction "foils brute force search hacking", which clearly isn't true. > In fact, it makes "brute force search hacking" easier. > > Had the reply been "it makes dictionary attacks more difficult", that > would have been a perfectly sensible thing to say. I may have missed something here but my impression is that someone *knew* how people would react to the change in rules. As a consequence they would go from passwords of the form xxxxxxxx to xxxxxA&1 where A&1 are ASCII characters, thus losing three characters of entropy due to the rule change.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-14 04:24 +0000 |
| Message-ID | <mvkldd$7dt$1@speranza.aioe.org> |
| In reply to | #72778 |
In comp.lang.c Richard Damon <Richard@damon-family.org> wrote: > On 10/13/15 8:35 PM, krw wrote: >>> I agree. This is exactly the point you and I have been trying to make >>> for several postings. Choosing the order in which your brute force >>> loop performs the tests based upon 'other knowledge' in such a way that >>> *may* result in faster results makes it no less brute force. >> ...and I disagree. Using any information about the password in the >> search is not "brute force", just by the definition of the words. Just >> because you design search to include the entire set of possible >> combinations doesn't mean it's "brute force". You are using brains >> not brawn. > I will point out that making an argument about not being a 'brute force' > attack is falling into the fallacy of the Straw Man. The original > complaint was about adding the requirement to passwords making it easier > to crack an account. > Since this is dealing with the real world, the account cracker is NOT > limited to just using brute force, but any means available. You do have to be careful, though. One important key to breaking the German Enigma in WWII was that it never encyphered a letter to itself. That doesn't sound like a big change, but it turns out that it really is. -- glen
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-14 20:47 -0400 |
| Message-ID | <3ntt1bp71nvgigsben753ach0fvblr9eov@4ax.com> |
| In reply to | #72800 |
On Wed, 14 Oct 2015 04:24:13 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >In comp.lang.c Richard Damon <Richard@damon-family.org> wrote: >> On 10/13/15 8:35 PM, krw wrote: >>>> I agree. This is exactly the point you and I have been trying to make >>>> for several postings. Choosing the order in which your brute force >>>> loop performs the tests based upon 'other knowledge' in such a way that >>>> *may* result in faster results makes it no less brute force. > >>> ...and I disagree. Using any information about the password in the >>> search is not "brute force", just by the definition of the words. Just >>> because you design search to include the entire set of possible >>> combinations doesn't mean it's "brute force". You are using brains >>> not brawn. > >> I will point out that making an argument about not being a 'brute force' >> attack is falling into the fallacy of the Straw Man. The original >> complaint was about adding the requirement to passwords making it easier >> to crack an account. > >> Since this is dealing with the real world, the account cracker is NOT >> limited to just using brute force, but any means available. > >You do have to be careful, though. > >One important key to breaking the German Enigma in WWII was that it >never encyphered a letter to itself. That doesn't sound like a big >change, but it turns out t > That gives you a big hint that you have the key (certainly helpful with the automated cracking) but is there another reason? The Germans did almost everything wrong.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-13 23:01 -0400 |
| Message-ID | <ebhr1bt1pb3jh7t6tk2g7kch52uq8iqmeg@4ax.com> |
| In reply to | #72742 |
On Tue, 13 Oct 2015 22:17:29 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >Reductio ad absurdum, so I conclude that krw is talking nonsense. Ye haa! Now watch how the stupid twerp responds to this proper prodding.
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-14 20:44 -0400 |
| Message-ID | <qjtt1b1qsdibpug0s11k7gtkiibc67an3a@4ax.com> |
| In reply to | #72787 |
On Tue, 13 Oct 2015 23:01:42 -0400, DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote: >On Tue, 13 Oct 2015 22:17:29 +0100, Richard Heathfield <rjh@cpax.org.uk> >Gave us: > >>Reductio ad absurdum, so I conclude that krw is talking nonsense. > > > Ye haa! Now watch how the stupid twerp responds to this proper >prodding. You're really convincing the people in CLC and SC that you really are always wrong, AlwaysWrong. You just can't help it.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-14 21:11 -0400 |
| Message-ID | <b9vt1bl6b19a0p9d6c61vqbq0jush6jrk4@4ax.com> |
| In reply to | #72901 |
On Wed, 14 Oct 2015 20:44:04 -0400, krw <krw@nowhere.com> Gave us: >On Tue, 13 Oct 2015 23:01:42 -0400, DecadentLinuxUserNumeroUno ><DLU1@DecadentLinuxUser.org> wrote: > >>On Tue, 13 Oct 2015 22:17:29 +0100, Richard Heathfield <rjh@cpax.org.uk> >>Gave us: >> >>>Reductio ad absurdum, so I conclude that krw is talking nonsense. >> >> >> Ye haa! Now watch how the stupid twerp responds to this proper >>prodding. > >You're really convincing the people in CLC and SC that you really are >always wrong, AlwaysWrong. You just can't help it. Run, Krud Rejects Wisdom... RUN!
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-14 22:26 -0400 |
| Message-ID | <7k3u1bldfblgun2u3jne1tsbrtur1hnrji@4ax.com> |
| In reply to | #72908 |
On Wed, 14 Oct 2015 21:11:48 -0400, DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote: >On Wed, 14 Oct 2015 20:44:04 -0400, krw <krw@nowhere.com> Gave us: > >>On Tue, 13 Oct 2015 23:01:42 -0400, DecadentLinuxUserNumeroUno >><DLU1@DecadentLinuxUser.org> wrote: >> >>>On Tue, 13 Oct 2015 22:17:29 +0100, Richard Heathfield <rjh@cpax.org.uk> >>>Gave us: >>> >>>>Reductio ad absurdum, so I conclude that krw is talking nonsense. >>> >>> >>> Ye haa! Now watch how the stupid twerp responds to this proper >>>prodding. >> >>You're really convincing the people in CLC and SC that you really are >>always wrong, AlwaysWrong. You just can't help it. > > Run, Krud Rejects Wisdom... RUN! I have you pegged, AlwaysWrong. ...not that it's difficult. Read a few of your posts and it's perfectly clear.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-13 18:48 +0000 |
| Message-ID | <mvjjmh$qef$1@dont-email.me> |
| In reply to | #72722 |
In sci.crypt krw <krw@nowhere.com> wrote: > On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh > <unruh@invalid.ca> wrote: > >On 2015-10-13, krw <krw@nowhere.com> wrote: > >> On Tue, 13 Oct 2015 00:44:45 +0000 (UTC), William Unruh > >><unruh@invalid.ca> wrote: > >> > >>>On 2015-10-13, krw <krw@nowhere.com> wrote: > >>>> On Mon, 12 Oct 2015 17:46:35 +0100, Richard Heathfield > >>>><rjh@cpax.org.uk> wrote: > >>>> > >>>>>On 12/10/15 17:20, DecadentLinuxUserNumeroUno wrote: > >>>>>> On Mon, 12 Oct 2015 14:25:16 +0100, Richard Heathfield <rjh@cpax.org.uk> > >>>>>> Gave us: > >>>>>> > >>>>>>> On 12/10/15 13:59, DecadentLinuxUserNumeroUno wrote: > >>>>>>>> On Mon, 12 Oct 2015 12:08:57 +0100, Bartc <bc@freeuk.com> Gave us: > >>>>>>>> > >>>>>>> <snip> > >>>>>>>>> > >>>>>>>>> Adding the restriction makes it easier to crack. > >>>>>>>> > >>>>>>>> It may makes the list of valid keys smaller, > >>>>>>> > >>>>>>> Right. > >>>>>>> > >>>>>>>> but the hack computer is > >>>>>>>> not aware of the restriction, > >>>>>>> > >>>>>>> Wrong. That's public knowledge, so you have to assume your adversary > >>>>>>> knows it. > >>>>>>> > >>>>>>> <snip> > >>>>>> > >>>>>> This is NOT true. The key requisites at my workplace are NOT "public > >>>>>> knowledge". > >>>>> > >>>>>The Web site under discussion is the Intel community Web site. Is that > >>>>>your workplace? If so, then I'm sorry to have to tell you that even > >>>>>Skybuck Flying knows the validation rules (unless, of course, he's got > >>>>>them wrong, which is always possible) and now so do sci.crypt, > >>>>>comp.lang.c, and sci.electronics.design subscribers. > >>>> > >>>> Please understand that the person you're responding to is universally > >>>> known as "AlwaysWrong" on SED. > >>>> > >>>>>And if it isn't your workplace, then your workplace's key validation > >>>>>rules are not, strictly speaking, relevant to the discussion. > >>>>> > >>>>>Furthermore, Kerckhoffs's Principle requires that you plan against the > >>>>>possibility that your adversary has the algorithm available for his > >>>>>inspection. He worded it as follows: "Il faut qu?il n?exige pas le > >>>>>secret, et qu?il puisse sans inconv?nient tomber entre les mains de > >>>>>l?ennemi" which, roughly translated, means "[The cryptosystem] shouldn't > >>>>>need to be secret, and if it falls into enemy hands that shouldn't be a > >>>>>big deal". (Obviously he doesn't mean the key itself.) > >>>> > >>>> Restated: "Security through obscurity isn't security at all." > >>>>> > >>>>>> And all brute force hacks try ALL keys. They do not discredit any, as > >>>>>> you have. > >>>>> > >>>>>All *valid* keys. Otherwise, all brute force attacks would have to try > >>>>>infinitely many keys despite there being an upper limit on key length, > >>>>>and that's obviously impossible. Brute force is a last resort and takes > >>>>>*ages*, so any shortcuts that /can/ be applied /are/ applied. > >>>>>Adversaries are not constrained by your desire for brute force to be > >>>>>harder than it needs to be. > >>>> > >>>> No, they only try half (on average). ;-) > >>>> > >>> > >>>Well, if they have a good heuristic as to how you choose your keys, it > >>>is much much less than half that they try, on average. > >> > >> Then it's not "brute force". > > > >Sure it is. Brute force says nothing about the order in which all the > >keys are tried. > Wrong. That's exactly what the term means. No thought, just pure > muscle. Nope, it is you that is wrong. Brute force simply means "try keys until one that works is found". It places no requirement upon the order in which you test the keys. You can try them forward, backwards, in a random order, or in an order that is likely to test the most likely candidates first, but it is still "brute force". It is still "brute force" because you are simply "trying keys until one is found".
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-10-13 13:24 -0600 |
| Message-ID | <1bfv1einbb.fsf@pfeifferfamily.net> |
| In reply to | #72731 |
Rich <rich@example.invalid> writes: > In sci.crypt krw <krw@nowhere.com> wrote: > >> Wrong. That's exactly what the term means. No thought, just pure >> muscle. > > Nope, it is you that is wrong. Brute force simply means "try keys > until one that works is found". It places no requirement upon the > order in which you test the keys. You can try them forward, backwards, > in a random order, or in an order that is likely to test the most > likely candidates first, but it is still "brute force". It is still > "brute force" because you are simply "trying keys until one is found". That definition would call a binary search in a sorted array "brute force". To the extent that the order you try keys is based on knowledge, it isn't brute force.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-13 22:23 +0100 |
| Message-ID | <mvjslf$5dr$1@dont-email.me> |
| In reply to | #72734 |
On 13/10/15 20:24, Joe Pfeiffer wrote:
> Rich <rich@example.invalid> writes:
<snip>
>> It is still
>> "brute force" because you are simply "trying keys until one is found".
>
> That definition would call a binary search in a sorted array "brute
> force".
No, because in a binary search you exclude half the keys at every step,
so you will never search them all.
Consider the following search:
{ 0, 1, 2, 3, 4, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 16 }
Search for: 8
{ 0, 1, 2, 3, 4, 5, 6, **7**, 9, 10, 11, 12, 13, 14, 15, 16 }
No, 7's no good. We want something bigger.
0, 1, 2, 3, 4, 5, 6 are eliminated from consideration without being
tested. 7 was tested.
{ 9, 10, 11, **12**, 13, 14, 15, 16 }
No, 12's no good. We want something smaller.
0, 1, 2, 3, 4, 5, 6, 13, 14, 15, 16 are eliminated from consideration
without being tested. 7 and 12 were tested.
{ 9, **10**, 11 }
No, 10's no good. We want something smaller.
0, 1, 2, 3, 4, 5, 6, 11, 13, 14, 15, 16 are eliminated from
consideration without being tested. 7, 10, 12 and (in the final
iteration) 9 were tested.
So we only tested a quarter of the keys, even though we didn't find what
we were looking for. So no, binary search is not brute force.
--
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 | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-13 20:36 -0400 |
| Message-ID | <sr8r1btcj5nvf3ugup570o8umvrfs6a318@4ax.com> |
| In reply to | #72734 |
On Tue, 13 Oct 2015 13:24:40 -0600, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote: >Rich <rich@example.invalid> writes: > >> In sci.crypt krw <krw@nowhere.com> wrote: >> >>> Wrong. That's exactly what the term means. No thought, just pure >>> muscle. >> >> Nope, it is you that is wrong. Brute force simply means "try keys >> until one that works is found". It places no requirement upon the >> order in which you test the keys. You can try them forward, backwards, >> in a random order, or in an order that is likely to test the most >> likely candidates first, but it is still "brute force". It is still >> "brute force" because you are simply "trying keys until one is found". > >That definition would call a binary search in a sorted array "brute >force". To the extent that the order you try keys is based on >knowledge, it isn't brute force. Exactly.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-13 22:59 -0400 |
| Message-ID | <b6hr1bt4i2vo0pi6bb4ivub400rmdokcmj@4ax.com> |
| In reply to | #72734 |
On Tue, 13 Oct 2015 13:24:40 -0600, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> Gave us: >Rich <rich@example.invalid> writes: > >> In sci.crypt krw <krw@nowhere.com> wrote: >> >>> Wrong. That's exactly what the term means. No thought, just pure >>> muscle. >> >> Nope, it is you that is wrong. Brute force simply means "try keys >> until one that works is found". It places no requirement upon the >> order in which you test the keys. You can try them forward, backwards, >> in a random order, or in an order that is likely to test the most >> likely candidates first, but it is still "brute force". It is still >> "brute force" because you are simply "trying keys until one is found". > >That definition would call a binary search in a sorted array "brute >force". To the extent that the order you try keys is based on >knowledge, it isn't brute force. ALL "brute force" engines are structured inasmuch as they all have a starting point and not all start at the same point. So that decision process alone makes them structured to some degree.
[toc] | [prev] | [next] | [standalone]
Page 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web