Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #202361 > unrolled thread
| Started by | peter@easthope.ca |
|---|---|
| First post | 2018-11-13 18:10 +0100 |
| Last post | 2018-11-15 01:10 +0100 |
| Articles | 11 on this page of 31 — 10 participants |
Back to article view | Back to linux.debian.user
Password policy. peter@easthope.ca - 2018-11-13 18:10 +0100
Re: Password policy. Reco <recoverym4n@enotuniq.net> - 2018-11-13 18:30 +0100
Re: Password policy. Gene Heskett <gheskett@shentel.net> - 2018-11-13 18:50 +0100
Re: Password policy. Reco <recoverym4n@enotuniq.net> - 2018-11-13 20:10 +0100
Re: Password policy. Gene Heskett <gheskett@shentel.net> - 2018-11-13 22:50 +0100
Re: Password policy. Reco <recoverym4n@enotuniq.net> - 2018-11-14 05:40 +0100
Re: Password policy. peter@easthope.ca - 2018-11-13 21:00 +0100
Re: Password policy. Dan Ritter <dsr@randomstring.org> - 2018-11-13 21:10 +0100
Re (2): Password policy. peter@easthope.ca - 2018-11-13 22:20 +0100
Re: Re (2): Password policy. Reco <recoverym4n@enotuniq.net> - 2018-11-14 05:40 +0100
Re: Password policy. Brian <ad44@cityscape.co.uk> - 2018-11-13 19:20 +0100
Re: Password policy. Jude DaShiell <jdashiel@panix.com> - 2018-11-13 19:40 +0100
Re: Password policy. Reco <recoverym4n@enotuniq.net> - 2018-11-13 20:10 +0100
Re: Password policy. Brian <ad44@cityscape.co.uk> - 2018-11-13 21:20 +0100
Re: Password policy. peter@easthope.ca - 2018-11-14 03:40 +0100
Re: Password policy. peter@easthope.ca - 2018-11-14 04:10 +0100
Re: Password policy. Brian <ad44@cityscape.co.uk> - 2018-11-14 10:50 +0100
Re: Password policy. Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-11-14 11:30 +0100
Re: Password policy. Corey Manshack <corey@manshack.me> - 2018-11-14 11:40 +0100
Re: Password policy. Corey Manshack <corey@manshack.me> - 2018-11-14 12:30 +0100
Re: Password policy. Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-11-14 12:30 +0100
Re: Password policy. Corey Manshack <corey@manshack.me> - 2018-11-14 13:20 +0100
Re: Password policy. Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-11-14 15:30 +0100
Re: Password policy. Brad Rogers <brad@fineby.me.uk> - 2018-11-14 16:50 +0100
Re: Password policy. Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-11-14 12:30 +0100
Re: Password policy. Brian <ad44@cityscape.co.uk> - 2018-11-14 12:20 +0100
Re: Password policy. Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-11-14 15:40 +0100
Re: Password policy. Brian <ad44@cityscape.co.uk> - 2018-11-14 17:00 +0100
Re: Password policy. Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-11-14 17:50 +0100
Re: Password policy. Brian <ad44@cityscape.co.uk> - 2018-11-14 21:30 +0100
Re: Password policy. Richard Hector <richard@walnut.gen.nz> - 2018-11-15 01:10 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> |
|---|---|
| Date | 2018-11-14 12:30 +0100 |
| Message-ID | <wU1wS-4Oi-13@gated-at.bofh.it> |
| In reply to | #202393 |
On 14/11/18 10:25 pm, Corey Manshack wrote: > So using the file uploader tool we can inject many more dangerous scripts and codes to gain higher access than just “reading” /etc/shadow if the uploader tool is running as privileged user or we gained privilege escalation another way. Sure, I never said it was a good example... In any case, weak passwords as per the "recommendation" are surprising to say the least. A.
[toc] | [prev] | [next] | [standalone]
| From | Corey Manshack <corey@manshack.me> |
|---|---|
| Date | 2018-11-14 13:20 +0100 |
| Message-ID | <wU2jf-5mx-5@gated-at.bofh.it> |
| In reply to | #202394 |
It may be that the Debian team is more in tune with their users. I’ve caught hell trying to convince old timers that their password of mark1 was incredibly horrible. People even tried to get me fired over my “strict” password policy. Sent from my iPhone > On Nov 14, 2018, at 7:28 PM, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote: > > > >> On 14/11/18 10:25 pm, Corey Manshack wrote: >> So using the file uploader tool we can inject many more dangerous scripts and codes to gain higher access than just “reading” /etc/shadow if the uploader tool is running as privileged user or we gained privilege escalation another way. > > Sure, I never said it was a good example... > > In any case, weak passwords as per the "recommendation" are surprising > to say the least. > > A. >
[toc] | [prev] | [next] | [standalone]
| From | Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> |
|---|---|
| Date | 2018-11-14 15:30 +0100 |
| Message-ID | <wU4l3-6EY-5@gated-at.bofh.it> |
| In reply to | #202399 |
On 14/11/18 11:09 pm, Corey Manshack wrote: > It may be that the Debian team is more in tune with their users. I’ve caught hell trying to convince old timers that their password of mark1 was incredibly horrible. People even tried to get me fired over my “strict” password policy. There is often a very weak link that you cannot do anything about; but of course, to them "you are the problem".... Dammed if you help them try to understand damned if you don't. Either way, lots of people have no clue as to why it is important and don't think that re-using the same stupid password all over the place is any kind of problem at all. :( Some bad practices never get found out as well, but you have to do what you can and perhaps one day they'll get bitten and realize that your warnings were for real and very much worth listening to.. A.
[toc] | [prev] | [next] | [standalone]
| From | Brad Rogers <brad@fineby.me.uk> |
|---|---|
| Date | 2018-11-14 16:50 +0100 |
| Message-ID | <wU5At-7on-1@gated-at.bofh.it> |
| In reply to | #202407 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, 15 Nov 2018 01:22:37 +1100
Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
Hello Andrew,
>you can and perhaps one day they'll get bitten and realize that your
>warnings were for real and very much worth listening to..
Experience (admittedly limited) tells me otherwise; Despite helping out
people and stressing the importance of security, I find it's the same
people time and time again that get burned in this way.
You can lead a horse to water......
--
Regards _
/ ) "The blindingly obvious is
/ _)rad never immediately apparent"
Now I found you out, I don't think you're so smart
Who Are You - Black Sabbath
[toc] | [prev] | [next] | [standalone]
| From | Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> |
|---|---|
| Date | 2018-11-14 12:30 +0100 |
| Message-ID | <wU1wR-4Oi-5@gated-at.bofh.it> |
| In reply to | #202391 |
On 14/11/18 9:28 pm, Corey Manshack wrote: > If they have /etc/shadow why would they need to brute force :) I can’t think of a vuln that would give that up without them already having root. A website file uploader tool, apparantly there has been one there for about 10 years using jquery. Once the file is uploaded, it can be leveraged to steel other files that the website shouldn't have access to. That's just one example. I'm sure there are many others. A.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2018-11-14 12:20 +0100 |
| Message-ID | <wU1nb-4Kz-5@gated-at.bofh.it> |
| In reply to | #202390 |
On Wed 14 Nov 2018 at 21:21:54 +1100, Andrew McGlashan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > On 14/11/18 8:44 pm, Brian wrote: > > On Tue 13 Nov 2018 at 18:50:35 -0800, peter@easthope.ca wrote: > >> https://en.wikipedia.org/wiki/Brute-force_attack > > > > Security is already breached if a password database can be attacked > > in that way. A six character (upper and lower case) login password > > would take about 500 years to force for someone at the keyboard. > > This assumes three seconds per try without coffee breaks. > > > > I'm the cautious type, so use ten character passwords. > > Well, yes.... but some breaches are from remote machines that may be > able to life the /etc/shadow file due to a vulnerability that isn't > fixed and if that's all they have, then they don't yet need more > direct access. If they have /etc/shadow, then they can work on > off-line brute force. There are two situations I can think of which could lead to /etc/shadow becoming vulnerable: 1. The machine's administrator causes it to happen. 2. There is a flaw in one the OS's components. The least said about cause 1, the better. There is nothing which can be done here. The bug arising in 2. would soon be discovered and a fix rapidly devised and distributed. There is nothing much to worry about here. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> |
|---|---|
| Date | 2018-11-14 15:40 +0100 |
| Message-ID | <wU4uJ-6Ix-7@gated-at.bofh.it> |
| In reply to | #202392 |
On 14/11/18 10:19 pm, Brian wrote: > There are two situations I can think of which could lead to /etc/shadow > becoming vulnerable: > > 1. The machine's administrator causes it to happen. > 2. There is a flaw in one the OS's components. > > The least said about cause 1, the better. There is nothing which can be > done here. > > The bug arising in 2. would soon be discovered and a fix rapidly devised > and distributed. There is nothing much to worry about here. Sometimes 2 doesn't get discovered for many years. How about: 3. They had physical access to the drive in question (or any backup) and that data wasn't encrypted (LUKS for example). [boot machine with live boot USB, mount root file system and steal the file, remove live boot USB, allow machine to startup normally] Oh and if the backup isn't protected, it could be in some AWS bucket or somewhere else with inadequate protection such as with a weak password on any cloud storage service. Now they've collected /etc/shadow one way or another and they can do as they please off-line. A.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2018-11-14 17:00 +0100 |
| Message-ID | <wU5K9-7sa-3@gated-at.bofh.it> |
| In reply to | #202408 |
On Thu 15 Nov 2018 at 01:30:02 +1100, Andrew McGlashan wrote: > > > On 14/11/18 10:19 pm, Brian wrote: > > There are two situations I can think of which could lead to /etc/shadow > > becoming vulnerable: > > > > 1. The machine's administrator causes it to happen. > > 2. There is a flaw in one the OS's components. > > > > The least said about cause 1, the better. There is nothing which can be > > done here. > > > > The bug arising in 2. would soon be discovered and a fix rapidly devised > > and distributed. There is nothing much to worry about here. > > Sometimes 2 doesn't get discovered for many years. A possibility, but remember that most security bugs are discovered proactively before there is an opportunity to exploit them. People do actively look for them and there are more goodies than baddies. In the case of someone discovering a way to take /etc/shadow, the event might not come to light for some time if exploitation is very low level and not against perceived high-value hosts. But eventually it would be noticed. And what is the value to an attacker in having /etc/shadow, assuming it can be decrypted in a sensible time frame? Remotely logging in? Surely not in these days of ssh keys? > How about: > > 3. They had physical access to the drive in question (or any backup) and > that data wasn't encrypted (LUKS for example). > [boot machine with live boot USB, mount root file system and steal the > file, remove live boot USB, allow machine to startup normally] You know what is said about physical access? This is 1. in disguise. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> |
|---|---|
| Date | 2018-11-14 17:50 +0100 |
| Message-ID | <wU6wx-80w-1@gated-at.bofh.it> |
| In reply to | #202418 |
On 15/11/18 2:51 am, Brian wrote: > And what is the value to an attacker in having /etc/shadow, assuming it > can be decrypted in a sensible time frame? Remotely logging in? Surely > not in these days of ssh keys? Well.... re-use of passwords. We all know that if you have a username (often times an email address) and the password used for that username, then there are too many places where that same credentials might be re-used elsewhere. A.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2018-11-14 21:30 +0100 |
| Message-ID | <wU9Xs-1SV-5@gated-at.bofh.it> |
| In reply to | #202421 |
On Thu 15 Nov 2018 at 03:41:42 +1100, Andrew McGlashan wrote: > > > On 15/11/18 2:51 am, Brian wrote: > > And what is the value to an attacker in having /etc/shadow, assuming it > > can be decrypted in a sensible time frame? Remotely logging in? Surely > > not in these days of ssh keys? > > Well.... re-use of passwords. > > We all know that if you have a username (often times an email address) > and the password used for that username, then there are too many places > where that same credentials might be re-used elsewhere. True, that is a possibility. But unless the attack is against a known user whose habits are also known or that can be guessed, knowing the password isn't dreadfully useful in itself. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Richard Hector <richard@walnut.gen.nz> |
|---|---|
| Date | 2018-11-15 01:10 +0100 |
| Message-ID | <wUdol-4h1-7@gated-at.bofh.it> |
| In reply to | #202418 |
[Multipart message — attachments visible in raw view] — view raw
On 15/11/18 4:51 AM, Brian wrote: >> How about: >> >> 3. They had physical access to the drive in question (or any backup) and >> that data wasn't encrypted (LUKS for example). >> [boot machine with live boot USB, mount root file system and steal the >> file, remove live boot USB, allow machine to startup normally] > You know what is said about physical access? This is 1. in disguise. Mistakes happen. Scenarios fail to occur to people. Go for defence in depth. Richard
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.debian.user
csiph-web