I’m disappointed that OSMC has a default password. I wish that OSMC would instead generate a random password when the user enables ssh. The password could be quite easy to use (i.e., type on another device without transcribing the password character for character) by using a diceware generator.
I’m not sure what children (helpful or otherwise) have to do with this.
The underlying issue is that there is currently a window for an attack between enabling ssh and logging in and changing the password. That is, assuming people even bother changing the password!
My request is based on my preference that machines are secure by default. There are many reports of attackers taking advantage of default passwords. I realize that this feature request represents a tiny amount of inconvenience to a few users, but I think this far outweighs the potential cost.
BTW, here are a few passwords generated by a diceware password generator:
message pray root
goods them put
win debate river
Those aren’t terribly hard to remember, I think. And, my request isn’t about forcing a particular password on a user, it’s just about the initial password.
By default your device is likely to only going to be accessible on your internal LAN and not accessible to anyone not already on your local network. If you don’t trust the people on your network enough to not compromise your device within the short period of time it takes to change the password (or disable SSH) then you have other issues.
I don’t really get how your password generation would work. If it’s just picking passwords from an existing precompiled list then that would surely be another way to gain access to others devices (as we’d all know what is in the list). Yes it’d take longer to guess than the default ‘easy’ password but some people would then assume they are secure and not change the password to at all. I’d much rather make it obvious that the default password is an ‘easy’ password so that should you need to secure your system more (I.e. You were exposing SSH to the WAN) then it’d be obvious that you need to change the password to something unique. Giving a false sense of security can be somewhat harmful.
How would this initial password be communicated to you?
You are arguing for weak security. Perhaps you don’t care who sees your dick pics. I think the world has enough crappy products, and the FOSS world should set a good example. In particular, I think that we should add security measures wherever they don’t inconvenience the user, which I don’t think my proposal does. (P.S. check out this article I read yesterday about the security of “security” cameras: https://www.reddit.com/r/privacy/comments/4ortwb/i_bought_and_returned_a_set_of_wifi_connected/ )
You can read about diceware here:
In short, there is a list of, say, 1024 simple words. To generate a password, we draw N random numbers from a uniform distribution and use them to index our word list. Assuming that N is 3, this gives us three words. Since each word contains 10 bits of entropy (log2(1024)=10), the resulting password has 30 bits of entropy, which isn’t great, but isn’t terrible either for a low security device. Assuming 10 password attempts per second, it would take 1.5 years to brute force such a password. (This assumes that the attacker knows the word list. The password contains more entropy if the attacker doesn’t know the word list.)
As for communicating the password, this is trivially done when the user enables ssh. Disabling and reenabling ssh via the GUI could just create a new password.
I’m assuming you’re also disappointed that nearly every wifi router on the planet is sold with a well known default username and password, such as ‘admin’ and ‘password’ ? I hope you’re contacting them too.
You’re aware that changing the ssh password or disabling ssh is one of the choices given to you through the user interface during the initial boot of the system ? It’s right there on the screen, you don’t need to log in with ssh to change the ssh password.
But seriously, who is going to try to hack into your device that is connected on your private LAN in the couple of minutes that you are going through the walkthrough ? If you have connected your device such that it has a publicly addressable IP address or has ssh port forwarded through (both strongly discouraged) then silly you.
There’s a good reason why ssh is enabled by default on a new install until the user turns it off. (If they choose to) It’s for troubleshooting purposes - without ssh its impossible to troubleshoot some problems such as a new install where no picture appears on a TV. If ssh was off by default it would be nearly impossible to troubleshoot a wide variety of problems that can currently be solved via ssh.
You can’t be serious can you ? Have you ever heard of dictionary attacks ?
Not really any need for this is there ?
Except it does inconvenience users, the first time they run into a problem that either causes no picture on their screen or requires a command line to troubleshoot or fix (for example kodi stuck in a sad face loop) - then they are stuck without being able to use ssh.
By the way, this debate has already been beaten to death here:
We have already added a page to the initial walkthrough that advises the user of the presence of an ssh server and gives them the chance to turn it off or change the password.
As users should not be putting their mediacenter devices on publicly accessible IP addresses or port forwarding to ssh without changing the password, we feel that this is the right balance between security and convenience to the user, so we are not planning to have ssh be off by default or using a random password.
Thanks for pointing me to the github issue, I hadn’t seen it. (In fact, I hadn’t found the issue tracker yet.)
Regarding proprietary software: yes, it is unfortunate, but I’m more concerned with FLOSS solutions providing sensible defaults.
As for dictionary attacks: it is possible to measure the security of diceware-generated passwords. The examples that I posted have 30 bits of entropy, which is a fair amount and should provide reasonable protection for protecting against network-based brute force attacks. Most human generated passwords (even those with multiple character classes, etc.) have much less.
I’m sorry that this one issue can cause you such disappointment.
I myself would not be disappointed either way, however it would have caused me endless frustration helping friends and family set this up over the phone if there was not the same password to tell them in each instance.
All of the people I know using OSMC do not have it exposed to the internet at large, as they have no idea how to do so. I would argue that those that do know how to would also know the inherent risks and take appropriate precautions. I personally do have ports forwarded for ssh, but not standard ports and I use keys rather than a password.
I also agree with Mandrake and feel there is no need for us to know that you store your dick picks on your OSMC device
I totaly agree with @neal, it is always a good idea to make a system as secure as possible by default (this is much more true since snowden!). And yes, surely it is a potential security problem to leave a system even for just a few minutes accessible via SSH with a default password. Imagine automated bots already sitting on your windows machine in the same LAN, scanning for hosts they can compromise.
So another idea: A user can choose to change the default password at the installer. So the password is changed before the system is accessible. You can even implement a random password generator there, which makes it harder for keyloggers to grab the password.
This will also be a statement regarding security by the osmc team - maybe use it for marketing. I am pretty sure there are many people out there, who will at least try your system, if they see that you take care of security (and the competitors dont).
But there are always priorities in a project and I am sure there are more important things to do - but maybe you can put it at least on your todo list
I have not seen said interview, I personally have found a lot of the media here in Australia has degraded into sensationalist tabloid B.S. and have sadly lost interest . But I take your word that you were merely quoting and retract my quip at your expense, with my apologies (perhaps use quotation marks?)
@hannes2323 change password at installer is a great solution, there is already an option to configure network here, so why not password. All a question of time and resources though.
while I didn’t really enjoy the presenter’s style, the interview was intriguing. Seemed to deal more with surveillance and intercepting data transmissions than actively accessing individual servers though.
Never the less, point taken. but extra security for OSMC shouldn’t compromise ease of installation, still think @hannes2323’s suggestion an excellent balance. Agree/Disagree? thoughts?
Enabling SSH by default and having a default username and password is a horrible idea. As far as convenience, the exploit that will be launched against such a simple attack surface will dramatically inconvenience users. This is as irresponsible as having default router passwords which have been used extensively in IOT attacks over the last few years. This is in fact a known risk that is more than a decade old, should not be ignored. See: https://www.sans.edu/cyber-research/security-laboratory/article/default-psswd
SSH should not be enabled by default
The username and password should not have a default (but rather be generated uniquely, or user-created)
All the explanations for why this is not a serious threat do not reduce the reality of the threat, which is not very difficult to fix.
Have you ever installed OSMC? Did you use the forum search or read the update notes from the OSMC blog to confirm that changes haven’t been made. It’s pretty obvious you did none of this and resurrecting a year old post to preach from your self perceived moral high horse is pretty poor trolling.