Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Sylvia Else Newsgroups: comp.misc Subject: Re: Ebay hacked Date: Mon, 26 May 2014 17:03:26 +1000 Lines: 48 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net Vg4ymtgjBwHO1cp9I2BZQAM2XP7RR4pgvikD1ajZs+2Tt0ACCD Cancel-Lock: sha1:5d6n08JuY7lWPfPY/6vOm+9VYTA= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: Xref: csiph.com comp.misc:3196 On 26/05/2014 6:53 AM, Paul Sture wrote: > On 2014-05-25, Sylvia Else wrote: >> On 25/05/2014 2:53 AM, Rich wrote: >> >>> >>> "Spaces and certain symbols (< >[ ]//) are not allowed in password." >>> >>> A properly designed password storage (using a hashing function such as >>> bcrypt or scrypt) does not care what symbols are in the password. >>> >>> Caring about specific symbols in the password implies they are not >>> following proper password storage models. >>> >> >> I wonder where the restriction is enforced - both on the client and at >> the server, or just in the client? How many here would be surprised if >> it were the latter? > > It would not surprise me to find that there was a server side restriction > at some time in the past, and they implemented client side validation for > that. > > Roll on a few years to the point where that server side restriction no > longer exists, but because folks have lost track of all the services > involved nobody can say for sure that nothing still has it. > > Thus the validation code lives on, and nobody has the guts to rip it out. > The concern is that the restriction exists to prevent some kind of injection vulnerability. If the restriction either never exists on the server, or is removed therefrom, then the vulnerability is exposed. Some while ago, I had to go to some considerable lengths to convince a senior system architect that a server could not trust client-side Java code. He was sure that doing so was how the banks had been implementing the Internet banking services. I dare say there are plenty of people who think that since you've just downloaded the code (Java, Javascript, or whatever) to the client, that the code can be trusted to do what you intend. It's hard to see how we'll ever get security when such fundamental misunderstandings persist. Sylvia.