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 <[email protected]>

Reply via email to