Password encription

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Password encription

j.emerlik
Hi,
which authentication mechanism should I use for SHA-256 password schama ?
Regards,
Jack
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

Aki Tuomi-2
PLAIN and LOGIN.


---Aki TuomiDovecot oy
-------- Original message --------From: "j.emerlik" <[hidden email]> Date: 25/10/2017  11:41  (GMT+02:00) To: Dovecot Mailing List <[hidden email]> Subject: Password encription
Hi,
which authentication mechanism should I use for SHA-256 password schama ?
Regards,
Jack
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

j.emerlik
In reply to this post by j.emerlik
Thx Aki,
with CRAP-MD5 as scheme and mechanism  it's works corretlly.

2017-10-25 10:52 GMT+02:00 Aki Tuomi <[hidden email]>:

> PLAIN and LOGIN.
>
>
>
> ---
> Aki Tuomi
> Dovecot oy
>
> -------- Original message --------
> From: "j.emerlik" <[hidden email]>
> Date: 25/10/2017 11:41 (GMT+02:00)
> To: Dovecot Mailing List <[hidden email]>
> Subject: Password encription
>
> Hi,
> which authentication mechanism should I use for SHA-256 password schama ?
> Regards,
> Jack
>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

Aki Tuomi-2
In reply to this post by j.emerlik
CRAM-MD5 should not be used. Its not terribly secure.


---Aki TuomiDovecot oy
-------- Original message --------From: "j.emerlik" <[hidden email]> Date: 25/10/2017  11:58  (GMT+02:00) To: Aki Tuomi <[hidden email]> Cc: Dovecot Mailing List <[hidden email]> Subject: Re: Password encription
Thx Aki,
with CRAP-MD5 as scheme and mechanism  it's works corretlly.

2017-10-25 10:52 GMT+02:00 Aki Tuomi <[hidden email]>:

> PLAIN and LOGIN.
>
>
>
> ---
> Aki Tuomi
> Dovecot oy
>
> -------- Original message --------
> From: "j.emerlik" <[hidden email]>
> Date: 25/10/2017 11:41 (GMT+02:00)
> To: Dovecot Mailing List <[hidden email]>
> Subject: Password encription
>
> Hi,
> which authentication mechanism should I use for SHA-256 password schama ?
> Regards,
> Jack
>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

j.emerlik
What scheme and mechanism do you recommend?

2017-10-25 11:01 GMT+02:00 Aki Tuomi <[hidden email]>:

> CRAM-MD5 should not be used. Its not terribly secure.
>
>
> ---Aki TuomiDovecot oy
> -------- Original message --------From: "j.emerlik" <[hidden email]>
> Date: 25/10/2017  11:58  (GMT+02:00) To: Aki Tuomi <[hidden email]>
> Cc: Dovecot Mailing List <[hidden email]> Subject: Re: Password
> encription
> Thx Aki,
> with CRAP-MD5 as scheme and mechanism  it's works corretlly.
>
> 2017-10-25 10:52 GMT+02:00 Aki Tuomi <[hidden email]>:
>
> > PLAIN and LOGIN.
> >
> >
> >
> > ---
> > Aki Tuomi
> > Dovecot oy
> >
> > -------- Original message --------
> > From: "j.emerlik" <[hidden email]>
> > Date: 25/10/2017 11:41 (GMT+02:00)
> > To: Dovecot Mailing List <[hidden email]>
> > Subject: Password encription
> >
> > Hi,
> > which authentication mechanism should I use for SHA-256 password schama ?
> > Regards,
> > Jack
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

Aki Tuomi-2
In reply to this post by j.emerlik
SHA512-CRYPT and PLAIN/LOGIN with SSL.
---Aki TuomiDovecot oy
-------- Original message --------From: "j.emerlik" <[hidden email]> Date: 25/10/2017  12:07  (GMT+02:00) To: Aki Tuomi <[hidden email]> Cc: Dovecot Mailing List <[hidden email]> Subject: Re: Password encription
What scheme and mechanism do you recommend?

2017-10-25 11:01 GMT+02:00 Aki Tuomi <[hidden email]>:

> CRAM-MD5 should not be used. Its not terribly secure.
>
>
> ---Aki TuomiDovecot oy
> -------- Original message --------From: "j.emerlik" <[hidden email]>
> Date: 25/10/2017  11:58  (GMT+02:00) To: Aki Tuomi <[hidden email]>
> Cc: Dovecot Mailing List <[hidden email]> Subject: Re: Password
> encription
> Thx Aki,
> with CRAP-MD5 as scheme and mechanism  it's works corretlly.
>
> 2017-10-25 10:52 GMT+02:00 Aki Tuomi <[hidden email]>:
>
> > PLAIN and LOGIN.
> >
> >
> >
> > ---
> > Aki Tuomi
> > Dovecot oy
> >
> > -------- Original message --------
> > From: "j.emerlik" <[hidden email]>
> > Date: 25/10/2017 11:41 (GMT+02:00)
> > To: Dovecot Mailing List <[hidden email]>
> > Subject: Password encription
> >
> > Hi,
> > which authentication mechanism should I use for SHA-256 password schama ?
> > Regards,
> > Jack
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

j.emerlik
Form me now is working SHA256-CRYPT and PLAIN/LOGIN with SSL/TLS.

2017-10-25 11:11 GMT+02:00 Aki Tuomi <[hidden email]>:

> SHA512-CRYPT and PLAIN/LOGIN with SSL.
> ---Aki TuomiDovecot oy
> -------- Original message --------From: "j.emerlik" <[hidden email]>
> Date: 25/10/2017  12:07  (GMT+02:00) To: Aki Tuomi <[hidden email]>
> Cc: Dovecot Mailing List <[hidden email]> Subject: Re: Password
> encription
> What scheme and mechanism do you recommend?
>
> 2017-10-25 11:01 GMT+02:00 Aki Tuomi <[hidden email]>:
>
> > CRAM-MD5 should not be used. Its not terribly secure.
> >
> >
> > ---Aki TuomiDovecot oy
> > -------- Original message --------From: "j.emerlik" <[hidden email]
> >
> > Date: 25/10/2017  11:58  (GMT+02:00) To: Aki Tuomi <[hidden email]
> >
> > Cc: Dovecot Mailing List <[hidden email]> Subject: Re: Password
> > encription
> > Thx Aki,
> > with CRAP-MD5 as scheme and mechanism  it's works corretlly.
> >
> > 2017-10-25 10:52 GMT+02:00 Aki Tuomi <[hidden email]>:
> >
> > > PLAIN and LOGIN.
> > >
> > >
> > >
> > > ---
> > > Aki Tuomi
> > > Dovecot oy
> > >
> > > -------- Original message --------
> > > From: "j.emerlik" <[hidden email]>
> > > Date: 25/10/2017 11:41 (GMT+02:00)
> > > To: Dovecot Mailing List <[hidden email]>
> > > Subject: Password encription
> > >
> > > Hi,
> > > which authentication mechanism should I use for SHA-256 password
> schama ?
> > > Regards,
> > > Jack
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

@lbutlr
In reply to this post by Aki Tuomi-2
On 25 Oct 2017, at 03:11, Aki Tuomi <[hidden email]> wrote:
> SHA512-CRYPT and PLAIN/LOGIN with SSL.

I’m happy with SHA256-CRYPT and PLAIN/LOGIN.

--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

Aki Tuomi-2


On 27.10.2017 08:37, @lbutlr wrote:
> On 25 Oct 2017, at 03:11, Aki Tuomi <[hidden email]> wrote:
>> SHA512-CRYPT and PLAIN/LOGIN with SSL.
> I’m happy with SHA256-CRYPT and PLAIN/LOGIN.
>
Yes. SHA256-CRYPT is good too. It was just recommendation over using
CRAM-MD5, use anything with salt.

Aki
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

j.emerlik
Aki,
if I understand it well, salt is useful when database is/was stolen ?
Then thief can use eg. rainbow tables to decrypt passwords.
Regards,
Jack

2017-10-27 7:42 GMT+02:00 Aki Tuomi <[hidden email]>:

>
>
> On 27.10.2017 08:37, @lbutlr wrote:
> > On 25 Oct 2017, at 03:11, Aki Tuomi <[hidden email]> wrote:
> >> SHA512-CRYPT and PLAIN/LOGIN with SSL.
> > I’m happy with SHA256-CRYPT and PLAIN/LOGIN.
> >
> Yes. SHA256-CRYPT is good too. It was just recommendation over using
> CRAM-MD5, use anything with salt.
>
> Aki
>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

Aki Tuomi-2
The use of salt, today, is to prevent the attacker from directly seeing
who has same passwords. Of course it also will make a rainbow table
attack less useful, but then again, no one uses rainbow tables anymore
since it takes about few minutes to brute force a password in the cloud
or on your home computer GPU. SHA512-CRYPT uses by default 4000 rounds
on dovecot, to make it more computationally expensive, but still it's
not very strong protection anymore.

MD5 with or without salt can be attacked at passwords per second speed,
so using CRAM-MD5 of DIGEST-MD5 is very very poor choice. Anything with
MD5 should not be used for passwords these days.

With Dovecot 2.3 we are making BLF-CRYPT available on all platforms, and
also adding support for ARGON2 when you have libsodium available.

Aki


On 27.10.2017 09:44, j.emerlik wrote:

> Aki,
> if I understand it well, salt is useful when database is/was stolen ?
> Then thief can use eg. rainbow tables to decrypt passwords.
> Regards,
> Jack
>
> 2017-10-27 7:42 GMT+02:00 Aki Tuomi <[hidden email]>:
>
>>
>> On 27.10.2017 08:37, @lbutlr wrote:
>>> On 25 Oct 2017, at 03:11, Aki Tuomi <[hidden email]> wrote:
>>>> SHA512-CRYPT and PLAIN/LOGIN with SSL.
>>> I’m happy with SHA256-CRYPT and PLAIN/LOGIN.
>>>
>> Yes. SHA256-CRYPT is good too. It was just recommendation over using
>> CRAM-MD5, use anything with salt.
>>
>> Aki
>>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

j.emerlik
You mean that today they using encrypted passwords to seeing
who has same passwords using brute force, hashes dictionary attack ?

2017-10-27 8:57 GMT+02:00 Aki Tuomi <[hidden email]>:

> The use of salt, today, is to prevent the attacker from directly seeing
> who has same passwords. Of course it also will make a rainbow table
> attack less useful, but then again, no one uses rainbow tables anymore
> since it takes about few minutes to brute force a password in the cloud
> or on your home computer GPU. SHA512-CRYPT uses by default 4000 rounds
> on dovecot, to make it more computationally expensive, but still it's
> not very strong protection anymore.
>
> MD5 with or without salt can be attacked at passwords per second speed,
> so using CRAM-MD5 of DIGEST-MD5 is very very poor choice. Anything with
> MD5 should not be used for passwords these days.
>
> With Dovecot 2.3 we are making BLF-CRYPT available on all platforms, and
> also adding support for ARGON2 when you have libsodium available.
>
> Aki
>
>
> On 27.10.2017 09:44, j.emerlik wrote:
> > Aki,
> > if I understand it well, salt is useful when database is/was stolen ?
> > Then thief can use eg. rainbow tables to decrypt passwords.
> > Regards,
> > Jack
> >
> > 2017-10-27 7:42 GMT+02:00 Aki Tuomi <[hidden email]>:
> >
> >>
> >> On 27.10.2017 08:37, @lbutlr wrote:
> >>> On 25 Oct 2017, at 03:11, Aki Tuomi <[hidden email]> wrote:
> >>>> SHA512-CRYPT and PLAIN/LOGIN with SSL.
> >>> I’m happy with SHA256-CRYPT and PLAIN/LOGIN.
> >>>
> >> Yes. SHA256-CRYPT is good too. It was just recommendation over using
> >> CRAM-MD5, use anything with salt.
> >>
> >> Aki
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

Joseph Tam-2
In reply to this post by j.emerlik
Aki Tuomi wrote:

> The use of salt, today, is to prevent the attacker from directly seeing
> who has same passwords. Of course it also will make a rainbow table
> attack less useful,

Not just less useful, but almost infeasible.  Given the use of random
salts, you would have to generate (number of possible salts) rainbow
tables.  This drastically changes the CPU/storage tradeoffs.

> but then again, no one uses rainbow tables anymore
> since it takes about few minutes to brute force a password in the cloud
> or on your home computer GPU. SHA512-CRYPT uses by default 4000 rounds
> on dovecot, to make it more computationally expensive, but still it's
> not very strong protection anymore.

I know it is theoretically possible, but really, how feasible is it?
The way people talk about it, they make it sound trivial.  As a test,
I just generated a hash using "doveadm pw".  Any takers?

  {SHA512-CRYPT}$6$qyQANQFbQGqOSqHh$Z4YVIe.QakXtWs63lWUmzlseKpiFzfPCKhwM0NQk8jP6QeRmk6POkCdSrFBmVO2wh.dgPCPA7Gq3sNUeKOZLM/

> MD5 with or without salt can be ATTAcked at passwords per second speed,
> so using CRAM-MD5 of DIGEST-MD5 is very very poor choice. Anything with
> MD5 should not be used for passwords these days.
>
> With Dovecot 2.3 we are making BLF-CRYPT available on all platforms, and
> also adding support for ARGON2 when you have libsodium available.

Straight hashes, without question, are weak.  I routinely break NTLM hashes
with rainbow tables.  I'm *not* arguing against the use of stronger
hashes, I'm just skeptical of the FUD surrounding the user of older
salted hashes.  This is especially true if the hashes are guarded
against leakage, as most are.  Strong crypt-hashes are an extra layer
of protection (defense in depth).

This page (if you trust 3rd parties) will report whether a password
was ever found in a breached databases.  You can also download the
SHA1 hashes of all their known cracked passwords.  It's big -- 5.3Gb
7-zipped file.

  https://haveibeenpwned.com/Passwords

"j.emerlik" further asks:

> You mean that today they using encrypted passwords to seeing
> who has same passwords using brute force, hashes dictionary attack ?

They precompute hashes for large number of password candidates, then
look up hashes in that table.  Rainbow tables are a way of folding large
tables into a smaller ones, trading off space for extra CPU time.

However, for hashes that use non-trivial salts, you would need to
precompute an astronomically large number of tables.  An attacker might
be better off with a straight CPU-bound brute force search.

Joseph Tam <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

Aki Tuomi-2

> On October 27, 2017 at 11:27 PM Joseph Tam <[hidden email]> wrote:
>
>
> Aki Tuomi wrote:
>
> > The use of salt, today, is to prevent the attacker from directly seeing
> > who has same passwords. Of course it also will make a rainbow table
> > attack less useful,
>
> Not just less useful, but almost infeasible.  Given the use of random
> salts, you would have to generate (number of possible salts) rainbow
> tables.  This drastically changes the CPU/storage tradeoffs.
>
> > but then again, no one uses rainbow tables anymore
> > since it takes about few minutes to brute force a password in the cloud
> > or on your home computer GPU. SHA512-CRYPT uses by default 4000 rounds
> > on dovecot, to make it more computationally expensive, but still it's
> > not very strong protection anymore.
>
> I know it is theoretically possible, but really, how feasible is it?
> The way people talk about it, they make it sound trivial.  As a test,
> I just generated a hash using "doveadm pw".  Any takers?
>
>   {SHA512-CRYPT}$6$qyQANQFbQGqOSqHh$Z4YVIe.QakXtWs63lWUmzlseKpiFzfPCKhwM0NQk8jP6QeRmk6POkCdSrFBmVO2wh.dgPCPA7Gq3sNUeKOZLM/
>

A random article on the internet says it's rather feasible if you want passwords cracked. Of course if the passwords are longer than, say, 8 characters, it becomes less feasible. My point wasn't to say that SHA512 is fully insecure, and adding rounds does make it less so as the expenses rack up.

https://killtacknine.com/test-driving-google-cloud-gpus-with-hashcat/

It's not available on the graphics (puzzling), but if you look at the gist, it'll show that SHA512-CRYPT is cracked at 247.9 kH/s and MD5-CRYPT (salted MD5) at 17579.7 kH/s. As comparison, straight non-salted SHA512 goes at 1402.7 MH/s and MD5 with no salting at 33677.6 MH/s. For reference, DIGEST-MD5 uses MD5(username:realm:password) as the stored credential, which is pretty much straight MD5 for cracking.

https://gist.github.com/anonymous/1fa176d82af79e879a9efa74c9d1c970

> > MD5 with or without salt can be ATTAcked at passwords per second speed,
> > so using CRAM-MD5 of DIGEST-MD5 is very very poor choice. Anything with
> > MD5 should not be used for passwords these days.
> >
> > With Dovecot 2.3 we are making BLF-CRYPT available on all platforms, and
> > also adding support for ARGON2 when you have libsodium available.
>
> Straight hashes, without question, are weak.  I routinely break NTLM hashes
> with rainbow tables.  I'm *not* arguing against the use of stronger
> hashes, I'm just skeptical of the FUD surrounding the user of older
> salted hashes.  This is especially true if the hashes are guarded
> against leakage, as most are.  Strong crypt-hashes are an extra layer
> of protection (defense in depth).
>

Yet these leaks, they seem to occur.

> This page (if you trust 3rd parties) will report whether a password
> was ever found in a breached databases.  You can also download the
> SHA1 hashes of all their known cracked passwords.  It's big -- 5.3Gb
> 7-zipped file.
>
>   https://haveibeenpwned.com/Passwords
>
> "j.emerlik" further asks:
>
> > You mean that today they using encrypted passwords to seeing
> > who has same passwords using brute force, hashes dictionary attack ?
>
> They precompute hashes for large number of password candidates, then
> look up hashes in that table.  Rainbow tables are a way of folding large
> tables into a smaller ones, trading off space for extra CPU time.
>
> However, for hashes that use non-trivial salts, you would need to
> precompute an astronomically large number of tables.  An attacker might
> be better off with a straight CPU-bound brute force search.
>
> Joseph Tam <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

Joseph Tam-2
On Sat, 28 Oct 2017, Aki Tuomi wrote:

> A random article on the internet ...

That would be funny to see in a bibliography.  "Accoring to [RANDOM] ..."

> says it's rather feasible if you want passwords cracked.  Of course if
> the passwords are longer than, say, 8 characters, it becomes less
> feasible.  My point wasn't to say that SHA512 is fully insecure, and
> adding rounds does make it less so as the expenses rack up.
>
> https://killtacknine.com/test-driving-google-cloud-gpus-with-hashcat/
>
> It's not available on the graphics (puzzling), but if you look at the
> gist, it'll show that SHA512-CRYPT is cracked at 247.9 kH/s and
> MD5-CRYPT (salted MD5) at 17579.7 kH/s.

Well, let's see.  The expected time to crack an 8 alphanumeric password
(pretty much scraping the bottom of the strength policy barrel)

  62^8/247900/2 ~ 14years (SHA512-CRYPT)
  62^8/17579700/2 ~ ~72 days (MD5-CRYPT)

Not trivial, but not reassuring, especially since processors get
faster.

>> This is especially true if the hashes are guarded against leakage, as
>> most are.  Strong crypt-hashes are an extra layer of protection
>> (defense in depth).
>
> Yet these leaks, they seem to occur.

True enough.  Case in point:

  https://techcrunch.com/2016/08/30/dropbox-employees-password-reuse-led-to-theft-of-60m-user-credentials/

  (Ironic note: even though half the passwords were using a straight
  SHA1 hash and thus much weaker, they did not leak the associated
  salt, and thus, were useless.  The bcrypt hashes though, included
  the salt and were vulnerable.)

Take away: use a strong password -- the hardest crypt algortihm in the
world can't save you if you don't.

Joseph Tam <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

j.emerlik
In reply to this post by Aki Tuomi-2
Aki,
I understand that salted passwords saved in my database and stronger hash
algorithm course that it will require more processor time/power to crack my
passwords.

But only when hackers have direct access to my database what means that
hackers have access to my passwords hashes (eg. hackers stolen my database).

My Dovecot use passwords saved in database as SHA256 and hackers can use
only SMTP, IMAP or POP3 services to try crack it using dictionary attack (I
understand that they using plain text dictionaty passwords).

Stronger hash algorithm and salt is useful when hackers have direct access
to my database but when they use services as SMTP, IMAP or POP3
to crack passwords only longer and more complicated password can be more
secure.

I do not understand this correctly ?

Regards,
Jacek



2017-10-28 0:39 GMT+02:00 Aki Tuomi <[hidden email]>:

>
> > On October 27, 2017 at 11:27 PM Joseph Tam <[hidden email]> wrote:
> >
> >
> > Aki Tuomi wrote:
> >
> > > The use of salt, today, is to prevent the attacker from directly seeing
> > > who has same passwords. Of course it also will make a rainbow table
> > > attack less useful,
> >
> > Not just less useful, but almost infeasible.  Given the use of random
> > salts, you would have to generate (number of possible salts) rainbow
> > tables.  This drastically changes the CPU/storage tradeoffs.
> >
> > > but then again, no one uses rainbow tables anymore
> > > since it takes about few minutes to brute force a password in the cloud
> > > or on your home computer GPU. SHA512-CRYPT uses by default 4000 rounds
> > > on dovecot, to make it more computationally expensive, but still it's
> > > not very strong protection anymore.
> >
> > I know it is theoretically possible, but really, how feasible is it?
> > The way people talk about it, they make it sound trivial.  As a test,
> > I just generated a hash using "doveadm pw".  Any takers?
> >
> >       {SHA512-CRYPT}$6$qyQANQFbQGqOSqHh$Z4YVIe.
> QakXtWs63lWUmzlseKpiFzfPCKhwM0NQk8jP6QeRmk6POkCdSrFBmVO2wh.
> dgPCPA7Gq3sNUeKOZLM/
> >
>
> A random article on the internet says it's rather feasible if you want
> passwords cracked. Of course if the passwords are longer than, say, 8
> characters, it becomes less feasible. My point wasn't to say that SHA512 is
> fully insecure, and adding rounds does make it less so as the expenses rack
> up.
>
> https://killtacknine.com/test-driving-google-cloud-gpus-with-hashcat/
>
> It's not available on the graphics (puzzling), but if you look at the
> gist, it'll show that SHA512-CRYPT is cracked at 247.9 kH/s and MD5-CRYPT
> (salted MD5) at 17579.7 kH/s. As comparison, straight non-salted SHA512
> goes at 1402.7 MH/s and MD5 with no salting at 33677.6 MH/s. For reference,
> DIGEST-MD5 uses MD5(username:realm:password) as the stored credential,
> which is pretty much straight MD5 for cracking.
>
> https://gist.github.com/anonymous/1fa176d82af79e879a9efa74c9d1c970
>
> > > MD5 with or without salt can be ATTAcked at passwords per second speed,
> > > so using CRAM-MD5 of DIGEST-MD5 is very very poor choice. Anything with
> > > MD5 should not be used for passwords these days.
> > >
> > > With Dovecot 2.3 we are making BLF-CRYPT available on all platforms,
> and
> > > also adding support for ARGON2 when you have libsodium available.
> >
> > Straight hashes, without question, are weak.  I routinely break NTLM
> hashes
> > with rainbow tables.  I'm *not* arguing against the use of stronger
> > hashes, I'm just skeptical of the FUD surrounding the user of older
> > salted hashes.  This is especially true if the hashes are guarded
> > against leakage, as most are.  Strong crypt-hashes are an extra layer
> > of protection (defense in depth).
> >
>
> Yet these leaks, they seem to occur.
>
> > This page (if you trust 3rd parties) will report whether a password
> > was ever found in a breached databases.  You can also download the
> > SHA1 hashes of all their known cracked passwords.  It's big -- 5.3Gb
> > 7-zipped file.
> >
> >       https://haveibeenpwned.com/Passwords
> >
> > "j.emerlik" further asks:
> >
> > > You mean that today they using encrypted passwords to seeing
> > > who has same passwords using brute force, hashes dictionary attack ?
> >
> > They precompute hashes for large number of password candidates, then
> > look up hashes in that table.  Rainbow tables are a way of folding large
> > tables into a smaller ones, trading off space for extra CPU time.
> >
> > However, for hashes that use non-trivial salts, you would need to
> > precompute an astronomically large number of tables.  An attacker might
> > be better off with a straight CPU-bound brute force search.
> >
> > Joseph Tam <[hidden email]>
>
Reply | Threaded
Open this post in threaded view
|

Re: Password encription

Joseph Tam-2
In reply to this post by j.emerlik
> Aki,

(Not speaking for Aki)

> I understand that salted passwords saved in my database and stronger hash
> algorithm course that it will require more processor time/power to crack my
> passwords.
>
> But only when hackers have direct access to my database what means that
> hackers have access to my passwords hashes (eg. hackers stolen my database).
>
> My Dovecot use passwords saved in database as SHA256 and hackers can use
> only SMTP, IMAP or POP3 services to try crack it using dictionary attack (I
> understand that they using plain text dictionaty passwords).
>
> Stronger hash algorithm and salt is useful when hackers have direct access
> to my database but when they use services as SMTP, IMAP or POP3
> to crack passwords only longer and more complicated password can be more
> secure.
>
> I do not understand this correctly ?

Yes, your understanding is basically correct.  However, history gives lots
of examples of broken systems that explicitly or implicitly relied on one
critical system not failing -- they lacked defense in depth or resilience.

Examples are "this system has no bugs", "my system does not leak hashes",
"this algorithm is unbreakable", "we'll never see a CAT5 hurricane", etc.
If these critical assumption ever becomes untrue, the foundation of your
defense crumbles.

If you narrow your attack definition to only include in-protocol remote
brute forcing, then any decent password will take far too long to break
that way (esp. with throttling controls that are built-in).  Your log
files will overflow recording the attempts long before you can expect a
password to be cracked.  However, you're still susceptable to the qwerty
passwords.  If this is your *only* line of defense, it is brittle.

A robustly secure system will overlap protection: strong hashes, password
compliance systems, brute force countermeasures, file permissions/OS
hardening, network origins vetting, anti-DoS measures, etc.

Keep this picture in mind that I found on CLCERT

  https://www.clcert.cl/humor/img/weakest-link-road.jpg

Joseph Tam <[hidden email]>