131–140 of 152 posts
Earlier quoted context omitted.
I'm beginning to think that IBM had the right idea witht he thumbprint scanners in the laptops. Fundamental flaw with that- you can't change your fingerprint if/when it is compromised.
Just switch fingers.
Earlier quoted context omitted.
anyone care to bet everyone with a linkedin account who works at a tech company just got targetted attacks? Hi, my name is Joe Hacker, and I work at ! Since you got my linkedin account, why not try that password at admin. ?
Anyone who uses the same password for their linkedin and company account earned their punishment for intentionally violating their company's information security.
Earlier quoted context omitted.
Yes, that's exactly what you do. In Django 1.4 (the latest), they store passwords using PDKDF2 or bcrypt. The nice thing is that it automatically upgrades the hash function if it used to be something else: _______ Password upgrading When users log in, if their passwords are stored with anything other than the preferred algorithm, Django will automatically upgrade the algorithm to the preferred one. This means that ol…
Couldn't you just move from, say, using MD5(password) to bcrypt(MD5(password))? So when it becomes apparent that the old hash is no more secure, start using the combination of the old bad hash (MD5) and the new good hash (bcrypt). This way you can simply run once through the password database, hash each password hash there with the new better hash, and throw away the old hashes. No need to prolong the process until t…
Though older APIs they're still used by many older or infrequently updated clients, such as hardware devices with sold with Last.fm integration.
Unfortunately, the longer you've been around the more likely you are to develop dependencies that make it more difficult to upgrade your password hashing.
A new site can do whatever it wants with password hashing, but it becomes harder for older sites with more legacy dependencies to make that kind of change and Last.fm has been around for almost 10 years.
This isn't to say "MD5 is cool, don't worry", but to try and illustrate some of the reasons behind this.
Apparently reporting the vulnerability to them 5(!) years ago was not enough :/
http://discuss.joyent.com/viewtopic.php?pid=139497
* Communicate over SSL/TLS (avoids session hijacking scenarios and is a reasonable choice in general)
* Hash AND Salt user passwords (we use PBKDF2)
Take one day and fix this in your own products & you just saved yourself a major PR disaster in the future :)
Earlier quoted context omitted.
Funnily enough I opened a new bank account the other day (Chase) and to my surprise they don't allow special characters to be used in the passwords. It indeed appears that the entire system is broken beyond repair. It seems like it is becoming the norm to expect to be exploited at some point so the de-facto preemption is to have someone to blame. As the manager of a datacenter we recently moved into said "we're here…
Many banks are encumbered by old mainframe systems that still do a lot of their computing. I don't know how much of that bubbles up through to the web interfaces we deal with, but I know many tellers and agents are still on green screens, or on interfaces that are just pretty wrappers to mainframe terminals.
It's not that easy to get rid of either, the banks have to support internal applications that expect things in those formats, as well as all the unofficial apps that plug in via messaging systems and may not be aware of the other app from either end.
Earlier quoted context omitted.
WTF, A YEAR AGO ?? They didn't notify users (i.e. me). Aren't they in breach of California law? Where are they based?
maybe they're just learning about it
Here's the method I use to manage website passwords: For logins that I don't really care about that much, say last.fm, I use my standard medium-strength 6 character password with a number and a capital letter, something like jfi3Jo. I can remember it because I use it often. For logins that I do care about like my email or bank I salt my base password by inserting three characters from the site's domain name into the…
[1] https://www.owasp.org/index.php/Session_hijacking_attack
PS: I'm leaving this comment without any reference to the site name, so I can copy and paste it verbatim in the future; it looks like this kind of breaches will not stop soon.
Earlier quoted context omitted.
FWIW, I did this a few years back (with 1Password, after having used Password Gorilla for a while). With the browser integration 1Password (and, I think keypass and lastpass) use, I think it's actually a productivity plus rather than a PITA...
Concur: I use 1password and lastpass. There are a couple of critical accounts that are actually wrong in each (non-overlapping) and a couple I still only have in my head, but overall it's a huge plus on a day-to-day basis. And it's an incredible relief to read these announcements, pull up my password for that site, and see it's 20 random characters that I know aren't useful on any other site.
Everything else is 16char upper/lower/digits/punctuation randomly generated by 1Password (except where I need t back that down for sites/services that wont accept that length/charset).
I've also got my random 16char AppleID password in my head, since I end up entering that often enough into place 1Password can't autofill.
I _think_ that's "paranoid enough" at least for now.
One thing I'd like 1Password to do, is bug me about passwords that haven't been changed in some (configurable per login) time. I'm pretty sure in 2 years (or less) I'm unlikely to consider 16char passwords "long enough".