Security and Default Passwords


11 posts
by louisb » Tue Jun 05, 2012 6:43 am
Hi all,

Now that Raspbian is getting ready for mainstream release I should point of that having a default username and password is a massive security hole especially as SSH is enabled by default. It is worse than having no password as it gives the user a false sense of security by religiously typing in this public password eachtime.

Perhaps this can be fixed by a first time start-up script that asks the users for a user name and creates a new user when Raspbian is powered up for the first time.

I think passwords are not so important on a kids machine and we should respect the user/parents wishes on not having passwords to login. However if any user wants to have a remote access via ssh then we should insists that all password are setup. It is the remote access that really worries me. People are putting up these as web servers but with the front door wide open when using a default username and password.

Perhaps someone other than mike or Plugwash could take this on with their agreement of course. Mike and Plugwash have contributed so much already and we should help them out wherever we can. But having default user name and password with SSH enabled is not good.

What do you all think about this?

Louis
Posts: 47
Joined: Wed Mar 07, 2012 7:08 am
by grumpyoldgit » Tue Jun 05, 2012 8:13 am
You are really going to shoot yourself in the foot with this. One of the major critisisms of the Fedora distro is the kak handed way it insists on changing passwords. It is a major pita and has put most people off. It has been instrumental in Fedora being effectively dumped by the foundation. While people are still having problems with power supplies, keyboards, SD cards, hubs and all the rest, adding further barriers in the form of password changes is a real no-no.
User avatar
Posts: 1458
Joined: Thu Jan 05, 2012 12:20 pm
by Joe Schmoe » Tue Jun 05, 2012 8:40 am
Totally agree, Gog.

Think of this as a 2x2 grid, with one variable being "System State" with values of "Setup/configuration" and "Stable, running". The other variable is "System Access", with values of "local only" and "local and remote". Now observe that in only one of the 4 boxes is it sensible to have (non-trivial) passwords (namely, Stable with remote access). In all other cases (the other 3 boxes in the grid), passwords just get in the way.

And note that:
1) We're going to be in "Setup/configuration" for the foreseeable future.
2) The intended use (portable device for kids to carry around with them and use at home for programming) is in the "local only" box.

I'm not saying there is no reason to worry about security, but I do think that calling it a "massive" security problem is typical online hyperbole.
Never answer the question you are asked. Rather, answer the question you wish you had been asked.

- Robert S. McNamara - quoted in "Fog of War" -
Posts: 2510
Joined: Sun Jan 15, 2012 1:11 pm
by rurwin » Tue Jun 05, 2012 9:30 am
Most of these devices are going to be used behind a router firewall that does not let in any traffic. One hopes that anyone with enough knowledge to set up a web server and drill a hole in the firewall for it, also has enough knowledge to change the password.

There are unlikely scenarios such as a "friend" installing a rootkit on it and getting access to a whole home network, but they are very unlikely, and even if the password has been changed a trusted friend will be given the new password. Other than that the risk is low and in my view only acts as a teaching exercise.

It's still only as insecure as a Windows PC with auto-login.
User avatar
Forum Moderator
Forum Moderator
Posts: 2903
Joined: Mon Jan 09, 2012 3:16 pm
by louisb » Tue Jun 05, 2012 9:59 am
If you read my original post carefully you will see that I am suggesting giving the users the option of having no password. Only when remote access is enabled is that a custom password should be set before remote access is enabled. I am certainly not suggesting password aging either. But we should not teach kids bad practices by leaving the remote access wide open to anyone who can see their pi and who can hack in just by type in the default username & password.
Posts: 47
Joined: Wed Mar 07, 2012 7:08 am
by louisb » Tue Jun 05, 2012 10:09 am
rurwin wrote:It's still only as insecure as a Windows PC with auto-login.


This is much worse than a PC with auto login. With auto login you have to be physically present to access the PC. A lot of people will be using pi as web servers. I am just saying we should not being using default/public passwords for remote access.
Posts: 47
Joined: Wed Mar 07, 2012 7:08 am
by bhoga » Tue Jun 05, 2012 10:38 am
rurwin wrote:One hopes that anyone with enough knowledge to set up a web server and drill a hole in the firewall for it, also has enough knowledge to change the password.


It's those kind of hopes that allow the proliferation of so many insecure "professionally hosted" web servers out there. I hear what you are saying, but in reality I believe we should teach best practice as early as we can ...
User avatar
Posts: 10
Joined: Sun Jun 03, 2012 7:33 pm
Location: Brighton, UK
by chrisw2 » Tue Jun 05, 2012 12:44 pm
louisb wrote:... Perhaps this can be fixed by a first time start-up script that asks the users for a user name and creates a new user when Raspbian is powered up for the first time.

...

What do you all think about this? ...


I think the installer http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=6532 is (or will be) the thing to use if you want that sort of set-up. It is based on the standard debian installer and does exactly what you describe above as one of its steps.
Posts: 106
Joined: Sat Apr 07, 2012 11:22 am
Location: Manchester, UK
by mpthompson » Tue Jun 05, 2012 6:12 pm
At this time, it looks like the person working on the next official Debian armel image from the Raspberry Pi Foundation will also be creating a parallel Raspbian armhf image that will mirror the Debian image feature-for-feature to the extent possible (of course, Raspbian will have the hardfloat and armv6 goodness). I don't know what the schedule for these images, but the Debian image will almost certainly be released first and then followed by the Raspbian based image. It is my understanding that those images will indeed have a "first time login" script that will mimic functionality of the installer including the setting of keyboard, locale, user accounts and passwords. Hopefully this will indeed be the case and I believe it should suite the legitimate concerns of the original poster.

Note: in addition to the passwords, a user of the Raspbian images should reset the ssh server keys stored on the system. Information on how to do this is here:

http://www.cyberciti.biz/faq/howto-rege ... host-keys/

I'll add this do the download instructions for the images.
User avatar
Forum Moderator
Forum Moderator
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
by DanielBarker » Wed Jun 06, 2012 1:09 pm
louisb wrote:If you read my original post carefully you will see that I am suggesting giving the users the option of having no password. Only when remote access is enabled is that a custom password should be set before remote access is enabled.


To me, this sounds a sensible idea.

Actually my guess is most people would be happy with just a default of: no password and all incoming remote-access switched off. On a principle of belt and braces, could there also be a software firewall, on by default and blocking most things?

This would be fine for most educational uses and would be a typical laptop/desktop situation.

The minority who want to set up some kind of server will have to have extra knowledge anyway.

Best wishes,

Daniel Barker
Posts: 43
Joined: Tue May 29, 2012 7:53 am
by Joe Schmoe » Wed Jun 06, 2012 1:31 pm
I agree, but note that one problem is that, because the Pi doesn't have an RTC (and there are plenty of threads about this) means that you almost need to have a network connected (since the days when you could just ignore the time issue have long since passed) in order to for the machine to be at all usable.

Further, a few months ago, people started to realize that they couldn't run the thing totally headless (that is, without *ever* connecting the usual peripherals) if SSH isn't enabled by default in the image (*); as a result, the pendulum has swung back to having it enabled. But that, of course, spawns the current discussion. What to do, what to do...


(*) Yes, since then we've realized a workaround - which is to edit the SD card from another box, renaming some RC file (but, alas, doesn't this require that other box to be Linux, since the RC files are in the ext4 partition. So, there you go, losing some of your audience again.
Never answer the question you are asked. Rather, answer the question you wish you had been asked.

- Robert S. McNamara - quoted in "Fog of War" -
Posts: 2510
Joined: Sun Jan 15, 2012 1:11 pm