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
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?
>
>
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
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
On Thu, 15 Nov 2018 01:22:37 +1100
Andrew McGlashan 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
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
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”
> pas
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, And
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.
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.
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, pe...@easthope.ca wrote:
> >> https://en.wikipedia.org/wiki/Brute-force_attack
> >
> > Security
-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, pe...@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
On Tue 13 Nov 2018 at 18:50:35 -0800, pe...@easthope.ca wrote:
> * From: Brian
> * Date: Tue, 13 Nov 2018 18:14:32 +
> > OTOH, if a*isvg is known to be the name of your dog...
>
> The reference in my enquiry is clear about that.
>
Hi.
On Tue, Nov 13, 2018 at 12:55:06PM -0800, pe...@easthope.ca wrote:
> Correct? No reliable means of testing a
> password without giving away the hashed password file exists?
It's rather 'no fast way of bruteforcing a password without giving away
its hash exists'.
You can always try
Hi.
On Tue, Nov 13, 2018 at 04:47:39PM -0500, Gene Heskett wrote:
> On Tuesday 13 November 2018 14:01:51 Reco wrote:
>
> > On Tue, Nov 13, 2018 at 12:49:17PM -0500, Gene Heskett wrote:
> > > On Tuesday 13 November 2018 11:23:13 pe...@easthope.ca wrote:
> > > > Hi,
> > > >
> > > >
* From: Brian
* Date: Tue, 13 Nov 2018 18:14:32 +
> OTOH, if a*isvg is known to be the name of your dog...
The reference in my enquiry is clear about that.
https://www.debian.org/doc/manuals/debian-reference/ch04.en.html#_good_password
Section 4.3.
"Do not choose guessable
* From: Brian
* Date: Tue, 13 Nov 2018 20:14:41 +
> OP sits tight and does not expand on what he wants to defend against.
To the best of my understanding a password is used to allow legitimate
access and prevent illegitimate access. More details in these pages.
On Tuesday 13 November 2018 14:01:51 Reco wrote:
> On Tue, Nov 13, 2018 at 12:49:17PM -0500, Gene Heskett wrote:
> > On Tuesday 13 November 2018 11:23:13 pe...@easthope.ca wrote:
> > > Hi,
> > >
> > > https://www.debian.org/doc/manuals/debian-reference/ch04.en.html#_
> > >good _password specifies
From: pe...@easthope.ca
Date: Tue, 13 Nov 2018 11:39:40 -0800
> We refer to two completely different processes or I completely miss
> the point.
Gene, in your scenario the crook has a copy of the hash of the
password file. Correct? No reliable means of testing a
password without giving
On Tue 13 Nov 2018 at 22:00:00 +0300, Reco wrote:
> Hi.
>
> On Tue, Nov 13, 2018 at 01:37:22PM -0500, Jude DaShiell wrote:
> > It's not even adequate against rainbow table hash attacks and hasn't
> > been for several years by now either.
>
> That's why they using salted hashes for
pe...@easthope.ca wrote:
> * From: Gene Heskett
> * Date: Tue, 13 Nov 2018 12:49:17 -0500
> > "John the ripper" can find a 6 char word in a couple seconds on a slow
> > machine.
>
> We refer to two completely different processes or I completely miss
> the point. After an incorrect
* From: Gene Heskett
* Date: Tue, 13 Nov 2018 12:49:17 -0500
> "John the ripper" can find a 6 char word in a couple seconds on a slow
> machine.
We refer to two completely different processes or I completely miss
the point. After an incorrect password is submitted, the
On Tue, Nov 13, 2018 at 12:49:17PM -0500, Gene Heskett wrote:
> On Tuesday 13 November 2018 11:23:13 pe...@easthope.ca wrote:
>
> > Hi,
> >
> > https://www.debian.org/doc/manuals/debian-reference/ch04.en.html#_good
> >_password specifies "6 to 8 characters". Is that adequate against
> >
Hi.
On Tue, Nov 13, 2018 at 01:37:22PM -0500, Jude DaShiell wrote:
> It's not even adequate against rainbow table hash attacks and hasn't
> been for several years by now either.
That's why they using salted hashes for passwords in /etc/shadow for the
last 15 years at least - and it's
It's not even adequate against rainbow table hash attacks and hasn't
been for several years by now either.
On Tue, 13 Nov 2018, pe...@easthope.ca wrote:
> Date: Tue, 13 Nov 2018 11:23:13
> From: pe...@easthope.ca
> To: debian-user@lists.debian.org
> Cc: pe...@easthope.ca
> Su
On Tue 13 Nov 2018 at 08:23:13 -0800, pe...@easthope.ca wrote:
> Hi,
>
> https://www.debian.org/doc/manuals/debian-reference/ch04.en.html#_good_password
> specifies "6 to 8 characters". Is that adequate against currently
> available brute force?
Much too fuzzy a question. You are going to
On Tuesday 13 November 2018 11:23:13 pe...@easthope.ca wrote:
> Hi,
>
> https://www.debian.org/doc/manuals/debian-reference/ch04.en.html#_good
>_password specifies "6 to 8 characters". Is that adequate against
> currently available brute force?
>
> Thanks, ...
Hi.
On Tue, Nov 13, 2018 at 08:23:13AM -0800, pe...@easthope.ca wrote:
> Hi,
>
> https://www.debian.org/doc/manuals/debian-reference/ch04.en.html#_good_password
> specifies "6 to 8 characters". Is that adequate against currently available
> brute force?
$ hashcat --session 6to8
Hi,
https://www.debian.org/doc/manuals/debian-reference/ch04.en.html#_good_password
specifies "6 to 8 characters". Is that adequate against currently available
brute force?
Thanks, ... Peter E.
--
Message composed and transmitted by software designed to
29 matches
Mail list logo
