Case sensitivity is a difficult problem when you might have non-English (ASCII) users. To the best of my knowledge I think that is it impossible to write an algorithm to perform a case-insensitive compare for the full UNICODE character set.
I hope I am wrong, as it is something I would find immensely useful. On Friday, September 14, 2012 2:51:26 AM UTC+1, Spooky wrote: > > On Thu, Sep 13, 2012 at 01:49:42PM -0700, bob wrote: > > > > 1. The comparison of the username and password is case-sensitive, which > it > > probably shouldn't be (*maybe* for password, probably not for username) > > Just FYI: > > I have never seen a case where the password is NOT case sensitive (that > would be a very bad thing). I take that back...I do remember one system, > and to make it worse, it used randomly-generated passwords (that forced > people to write them down), ALL UPPERCASE, and only letters ... nothing > else. A script kiddie would take about 5 minutes with crack to break > that. > > Likewise, usernames are generally not case-sensitive, with one exception > that may not exist anymore: Unix variants (including Linux). At least > in the past, if you logged on with all uppercase letters, the system > would assume that you were on a terminal that did not support lowercase, > and everything would be uppercase (so if you turned the caps lock key > off, you had to turn it back on to enter any commands). > > > 2. The passwords are stored insecurely in the database, whereas an MD5 > > hash would be preferred. > > Does the Android platform have any support for the usual password > handling like Unix's? That would be the most secure way to go. In > Unix (and variants), when you enter a password, it's encrypted, part of > the encrypted data is deleted, encrypted again, modified again, and so > on for some number of times. The encrypted password can not be reversed. > So when you log in later, the two encrypted versions are compared, and > if they match, you get logged in. I used to know the rest (the way it > was modified), but have long since forgotten. > > It's an expensive password routine, but it's also as secure as the > password used by the user (which is usually really bad, from what I > used to see long ago, when I, as the admin, ran crack on my users' > passwords all the time). If it's available in the SDK, that's what > I would recommend...just my $10 worth (inflation, you know), though. > > Later, > --jim > > -- > THE SCORE: ME: 2 CANCER: 0 > 73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion > > spook...@gmail.com <javascript:> ICBM/Hurr.: 30.44406N > 86.59909W > > Seen in alt.sysadmin.recovery: "Priceless; that's better than telling > him to use the Read Manual command with the Real Fast option." > > Android Apps Listing at http://www.jstrack.org/barcodes.html > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
