txt file is now down, can someone check if cptwhite at g***l dot com is on it?
txt file is now down, can someone check if cptwhite at g***l dot com is on it?
There's some confusion over other email accounts etc.
From what I can tell, basically this is a service which you just need an email account for, and then you register that email account (more or less as a username) and a password to use the service (just like google docs etc.). You would have to be quite stupid to use the same password for this as you do your email account that you used as your effective username, nevertheless, if you did register an account for yahoo voices, and you did use the same password for voices as you did the email account you registered with, then you are in trouble.
Last edited by kalniel; 13-07-2012 at 11:31 AM.
cptwhite_uk (27-07-2012)
I don't remember for certain - the registration process has changed over the years and now you need a yahoo, facebook or google account - but I would expect so.
Unless it's something like that facebook friend finder thing that forebordingly asks for your email address and the password to that account so it can rifle through your address book *shudder*. But I don't think it was like that. And anyone here would know if they had signed up to something like that I'm sure.
Now would be a good time to suggest a decent password manager, especially if you're using the same password for everything! I personally like+recommend KeePass and LastPass.
pretty sure mine shouldnt be on the list but can someone check that ***** is off that list?.
Need to spend a day putting all my passwords into a password manager, just keep forgetting!.
edit: Thanks WC!
Can't find you.![]()
Hicks12 (13-07-2012)
From what I gather you understood correctly, however if this was the case than that would also mean the user account data for other sites was travelling from one point to the other unencrypted as well, dramatically increasing the risks of this data being hacked into. A completely wrong way of doing this - user verification should have been done remotely by means of custom transport mechanisms invisible to the end user, using low level protocol stacks and, again, good point-to-point encryption. Remote databases should never have been cached locally just in case remote service is down, which would be infrequent at best with big players like those mentioned using all kinds of load-balancing and fail-proof tech available to them. It's just lame this has happened, I knew all this way before I wrote my first web application. On the other hand, programmers writing yahoo's code get paid probably 10 times more than I do, simply for delivering their solutions faster to the market. Buggy as it might be - to them it obviously didn't matter and thought they're eventually going to get there, as long as the service is running and making profits. Yahoo is long since in a nosedive and no one bothered to address those past issues. So there we have it. Seems making fun of your customer base pays better than supporting them with security features they most probably wouldn't understand anyway. That's why this world is getting more and more complicated each time we "automate" some process - we need to understand how these "automated" processes work in case those writing the code for them didn't. Sadly, this happens way more frequently than anyone would want it to. The fact that Facebook is written in PHP gives me the shivers. Or Wiki, for that matter, but Wiki's not so much of a potential issue concerning user data leaks as FB could be. "PHP programming" is an oxymoron from where I'm siting. And I'm not even using FB, however a large portion of my user base does, and guess who's going to play the role of a "web Paracetamol" when they catch cold using it? I don't like being cynical, but this will happen. Point in case - some of it already has. Cheers!![]()
As for your first point, I don't agree completely on that, and to keep it short here's a link to why: h**p://codahale.com/how-to-safely-store-a-password
(replace ** with tt in the link, I don't have 5 posts required to include URLs yet LOL)
I do agree with your second point, though, and have responded to the previous poster with similar thoughts. Cheers!![]()
You should never be using a single round of hashing; the amount of rounds should be tailored to the hardware it's run on and how much it has to do. I'm not saying bcrypt is inferior, just it'd not necessarily an advantage when both are properly implemented. Of course, salting does nothing for bruteforce, but rainbow attacks are orders of magnitude faster than bruteforce if you don't use salt.
There are currently 1 users browsing this thread. (0 members and 1 guests)