------------------------------------------------------------------------ A poll associated with this post was created, to vote and see the results, please visit http://forums.slimdevices.com/showthread.php?t=34909 ------------------------------------------------------------------------ Question: My opinion of this is... - I don't use RadioTime, and I think this is OK - I don't use RadioTime, but that sounds like a problem - I use RadioTime, and I don't care about these "flaws" - I use RadioTime, and this bothers me at least a bit ------------------------------------------------------------------------
Hi, radiobill. Quick question: do you work for RadioTime, or have you? radiobill;199017 Wrote: > The risk is much lower -- another user might guess a RadioTime account > name to listen to favorite stations. But the user would not be able to > identify your email > That's not true. When you submit a valid RadioTime username in the "forgot password" page (http://radiotime.com/SendPassword.aspx), the web site will display a message like "Your password has been sent to [EMAIL PROTECTED]", revealing the user's email address. > or your identity, nor would they be able to make any changes to your > RadioTime account. Since you don't enter a password for the SlimServer > or the SqueezeNetwork the password is never at risk See below for more discussion of the password risk. My concern is how the passwords are stored and processed in the RadioTime system, including those of RadioTime users who never use the SlimServer or SqueezeNetwork integration. > , much less the email used to register. > > Registration with RadioTime.com is secure and passwords entered into > radiotime.com and the RedButton TiVo-style Windows software are > protected. That's also not true. I don't know about the RedButton software, but the login process on the web site is not secure. The page that displays the login form and processes login attempts (http://radiotime.com/Login.aspx) is not secure. Nor is the page that's used to set up an account (http://radiotime.com/Enroll/QuickEnroll.aspx). RadioTime does appear to use secure web pages (https) when soliciting credit card information, as it is almost certainly required to do by its credit card processing contracts. > Obviously you'll want to use a lower risk password for casual sites like > RadioTime, as compared to a bank account or accounts with sensitive > information. Certainly it's a "best practice" for users to use better passwords for less "casual" sites like online banking. And if SqueezeNetwork required a user's RadioTime password to work (as it requires Live365 passwords), that should clearly suggest to the user that a "lower risk password" would be appropriate. But not all RadioTime users use the SN integration and, more importantly, it's also a best practice for site designers not to store passwords in "cleartext" or in an easily recoverable format, and not to send cleartext passwords via unencrypted channels like email -- but that's what RadioTime has done. Below is more detail on my findings, since you seem intent on questioning not only the importance of RadioTime's flaws, but the existence of the flaws. There might be some even more interesting (frightening!) combination attack possibilities. For instance, if RadioTime has not built good anti-CSRF measures into the portion of the web site that updates a user's profile, an attacker who knew a victim's email address might be able to write a simple attack that would send a RadioTime user's username and password to the attacker without the victim's knowledge. -Peter Suggestions for RadioTime: RadioTime: * Devise a new "forgot password" system that does not depend on recovering the "cleartext" password and convert every single stored user password to a strongly salted hash. * Modify your "forgot password" web interface so that it does not display "Your password has been sent to " + the user's email address * Modify your web applications so that https is used at least for displaying login forms and password maintenance forms and for processing logins, password changes, and any other user requests that include users' passwords. * Modify your APIs so that passwords are required and drop the old APIs. * Make sure your non-web login API uses https/SSL/TLS. * Reassess your system design in light of industry best practice and documents such as the Payment Card Industry Data Security Standard, the Open Web Application Security Project (OWASP) guidelines, etc. Privacy Issues RadioTime will provide account information without a password. Passwords are not required for obtaining information about a RadioTime user. RadioTime has an application programming interface (API) for accessing a user's "favorites" and local radio programming. This API does not require the user's password. By submitting a username to this API, an attacker could learn roughly where a RadioTime user lives, and what programming interests that user. RadioTime asserts that it monitors its systems for supicious activity, so large-scale data mining should be somewhat difficult, but small-scale stalking of individual users should be very easy for an attacker to undertake. RadioTime exposes email addresses The forgot password feature displays the email address to which it has sent a user's password reminder. An attacker who uses this flaw to learn the email address for a given username will leave a trace (the RadioTime user will get a password reminder email), but nonetheless can use this flaw to find email addresses. Security Issues Insecure password storage Radiotime stores users' passwords in a recoverable format. All common computer operating systems, and most applications that provide username/password logins, do not store a user's password "as-is", in "cleartext", but, rather, store a one-way "hash" of the password so that anyone who gains access to the stored passwords will not see the "cleartext" password. http://en.wikipedia.org/wiki/Password#Form_of_stored_passwords Some applications that store cleartext passwords warn users when they set up accounts.[1] RadioTime does not; by all appearances, RadioTime stores "cleartext" passwords. Since users often use the same password for multiple sites, this flaw may put RadioTime users at risk of having other accounts compromised through RadioTime's flawed security design. How much should you trust RadioTime? Their privacy policy[2] states that "When our registration/order form asks users to enter sensitive information..., that information is encrypted and is protected with the best encryption software in the industry - SSL. ... we use SSL encryption to protect sensitive information online" but RadioTime does not use https (SSL) to protect pages that ask users for their passwords, email address, zip code, etc. And their systems will send your password to you in an unencrypted email message. So it seems that RadioTime does not consider its customers passwords to be "sensitive" information. Web logins vulnerable to common attacks (sniffing, MITM) RadioTime does not use secure (https) web URLs for user logins. This makes RadioTime usernames and passwords visible to attackers who might be "sniffing" the network segments between a user's computer and RadioTime's servers even when things are working as designed. It also enables Man-In-The-Middle attacks whereby an attacker who controls a network segment between a user and RadioTime can impersonate RadioTime's server. -Peter Contact History: 2007 March 25: Private message sent to ThomasMark regarding "no password" privacy issue. No reply. 2007 April 16: Email sent to [EMAIL PROTECTED] regarding "no password" privacy issue. 2007 April 16: RadioTime email reply regarding "no password" privacy issue. 2007 April 17: Replied to RadioTime contact, raising issues of unencrypted logins and cleartext passwords, and requesting that my RadioTime account be deleted. No reply. 2007 April 23: Used RadioTime web form to request account deletion due to privacy & security concerns. No reply. 2007 April 25: Email sent to [EMAIL PROTECTED] to request account deletion due to privacy & security concerns. No reply by April 30 (No reply was ever sent to my initial address; I do not know if RadioTime emailed the address I set for my account on April 30.). 2007 May 2: My RadioTime account no longer exists. Footnotes: [1] The "mailman" mailing list software has language like the following on its signup forms: "You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext." [2] http://radiotime.com/privacy.aspx -- peterw http://www.tux.org/~peterw/ free plugins: http://www.tux.org/~peterw/#slim BlankSaver BottleRocket FuzzyTime SaverSwitcher SleepFade StatusFirst VolumeLock ------------------------------------------------------------------------ peterw's Profile: http://forums.slimdevices.com/member.php?userid=2107 View this thread: http://forums.slimdevices.com/showthread.php?t=34909 _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
