51–60 of 116 posts
Earlier quoted context omitted.
There's already a Chrome Extension for it if I'm not mistaken.
Can you share the name or link please?
Earlier quoted context omitted.
There's already a Chrome Extension for it if I'm not mistaken.
Can you share the name or link please?
digitalocean.com stored your password in plaintext!!!
Earlier quoted context omitted.
There are some ways to do that sort of thing safely, for some value of 'safe', but they're non-trivial. Sticking the plaintext passwords in a database row is trivial. Which do you think is more common? :-(
That's really trivial, and many web applications work this way: email = input.email plainPassword = input.password hashed = hash(plainPassword) saveToDb(email, hashed) sendGreetingEmail(email, plainPassword) Emailing a plain text password during registration is not the same as storing it forever in a database.
We already have a fairly good solution to this problem in OAuth. However, current popular implementations of OAuth are third-party owned which is not desirable for many reasons (for example, google won't use facebook owned OAuth, and vice-versa). Ideally, we should have a self-owned OAuth service implemented by browsers or operating systems. And the APIs of this service should be standardized. Also, the storage shoul…
I think that was Microsoft Passport. More recently, it's Mozilla Persona. The problem has always been a lack of incentives for websites to implement them, coupled with user indifference.
I would disagree. It's common knowledge (backed by many A/B tests) that shorter sign-up forms see less traffic drop. So, if OAuth can replace a number of things (name, email, password, email verification, and so on) by a couple of clicks, I as a website owner will be very happy. Also, when sending interesting emails to inactive users, I see quite a few come back but drop again after a few unsuccessful login attempts. Again, OAuth will help.
The reasons website owners (at least I) don't use facebook or google's OAuth are following:
1. They brand their service too much. The button itself says Login with Facebook/Google. I don't want my users' mind share to be consumed by them. Everything from login/logout to account management happens on pages in the context of their brand. Browser/OS providing this service is much less problematic, and even they should have pluggable services for replacing their default implementations, just like the ability to change the default browser on any OS.
2. They own the data and not the user. I have faced an incident in the past where one of my games was blocked by facebook because they thought it was gambling. I lost 95% of my users in one stroke. It took me two weeks haggling with FB to get my game whitelisted again. Still, the damage was done and we could never fully recover. The data must be owned by the end user and stored in open format so that user can take it freely from one place to another, just like I can take my contacts in vCard format to wherever I like.
3. Any such solution (especially when so heavily branded) will naturally turn other big players hostile. for example, facebook and google will have their own separate implementations instead of having a common one. This will almost ensure that standardization will hot take place. One button each for signup with Facebok/Google/LinkedIn/OpenID/... doesn't make for great UX and it's unnecessary overhead for website owners.
Mozilla persona is a good initiative. Hope they prefer standardization over trying to use it to promote their own browser.
Earlier quoted context omitted.
Even if it's not stored at their end in plaintext it's a security issue that it's emailed in plaintext.
There was an article on HN in the last week (or so) claiming that both inbound and outbound encryption of email was happening. http://readwrite.com/2014/06/06/google-gmail-encryption-fail... Correct me if I'm wrong but wouldn't this mean that only the email stored on the recipient's email provider's server was then unencrypted.
Should really start doing this for sites using MD5/SHA1 for password hashing too, as using them is barely above plain text in terms of security these days.
How so?
Should really start doing this for sites using MD5/SHA1 for password hashing too, as using them is barely above plain text in terms of security these days.
> as using them is barely above plain text in terms of security these days How so?
At minimum, you need to add unique salt to each password. It forces the attacker to run dictionary on each account separately. It is also recommended to use different slower hash function or iterate MD5/SHA1 thousands times, so he will be much slower.
Hey guys, I'm @omervk, one of the co-founders and the maintainer of PTO. Always a pleasure to be featured on the front page of HN. You're welcome to ask me questions, though we've covered most on our about page ( http://plaintextoffenders.com/about ). The one we haven't is usually "Is there an API/better search/new site coming?" to which the answer is that we're both doing this in our spare time and though we really…
For good measure you should list websites allowing you to enter a password on a non-https page, too. That's plain text, too.
Hey guys, I'm @omervk, one of the co-founders and the maintainer of PTO. Always a pleasure to be featured on the front page of HN. You're welcome to ask me questions, though we've covered most on our about page ( http://plaintextoffenders.com/about ). The one we haven't is usually "Is there an API/better search/new site coming?" to which the answer is that we're both doing this in our spare time and though we really…
Great stuff, although it would be nice to have the list of sites in a more usable format - browsing through individual blog posts looking for a domain isn't particularly efficient. Have you thought about reporting on other aspects of password security, such as misguided length limits or character requirements? Edit: sorry, I guess you've just about covered my first point.