The login process looks like:  User navigates to login screen and sends plaintext password to server.  Server hashes the plaintext password and compares it to the hash on disk.  If the hashes are equal, the server grants access.<p>Since a user can only submit a plaintext password, not a hash, then they won&#x27;t be able to log in unless they know the correct plaintext password.  Even if they have a copy of the server&#x27;s db, they won&#x27;t be able to use any info within it to log in as anyone else unless they use brute force to reverse a hash.<p>EDIT: It&#x27;s true that the attacker might have a copy of all the user&#x27;s data.  But unless they know someone&#x27;s plaintext password, they can&#x27;t log in as them.  The attacker might have a copy of your tweets, but they won&#x27;t be able to log in as you and send a new one.<p>There are only a few ways an attacker can snag a database.  Most of the attacks let an attacker download it, but not modify it.   For example, directory traversal lets you download ..&#x2F;..&#x2F;..&#x2F;..&#x2F;etc&#x2F;passwd along with ..&#x2F;..&#x2F;path&#x2F;to&#x2F;database_backup.<p>Even if an attacker has shell access, it&#x27;s unlikely they&#x27;d be able to use the service or change a user&#x27;s password by manipulating the database directly.  They might not be able to modify database for a number of reasons: the database might require credentials the attacker didn&#x27;t get, or the attacker might only have access to a server containing database dumps rather than the database itself, or the attacker might be logging in as a user which has read-only access to the database file.