Password encription

[Joseph Tam]

> 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 <jtam.home at gmail.com>