# BRUTEFORCE Password Cracker question.

**URL:** <https://boards.straightdope.com/t/bruteforce-password-cracker-question/108052>\
**Category:** Factual Questions\
**Created:** [May 9, 2002, 10:19am UTC](https://boards.straightdope.com/t/bruteforce-password-cracker-question/108052 "2002-05-09T10:19:53Z")\
**Posts on this page:** 1\
**Page:** 2

<div class="post-metadata">

**Author:** ![evilhanz](https://avatars.discourse-cdn.com/v4/letter/e/ba8739/32.png) [@evilhanz](https://boards.straightdope.com/u/evilhanz)\
**Post date:** [May 10, 2002, 3:55pm UTC](https://boards.straightdope.com/t/bruteforce-password-cracker-question/108052/21 "2002-05-10T15:55:31Z")

</div>

> [@](#):
>
> \*Originally posted by Phlip \*  
> \*\*That was what I was wondering. I wasn’t sure if a BRTUEFORCE methos would work on a web form because of the delay. I am guessing that is would also bog the server down would it not? \*\*

If the password is being submitted from a non-secure, unencrypted webpage, you might as well have no security at all. If the passwords are stored in a file somewhere in the web directory structure and not in a remote database, that’s even worse. If any of the above is true, then brute force isn’t necessary to obtain passwords or bypass the login screen. At the very least, you should implement a challenge response system with a maximum number of retries before disabling the account. You should also implement a better password picking policy. I’m surprised that you have developers coding it any other way… well, maybe I shouldn’t be. 🙂

[Previous page](https://boards.straightdope.com/t/bruteforce-password-cracker-question/108052.md?page=1)