Store passwords encrypted

Please confirm, are you concerned about the way the password is stored in the Drupal DB or passed to the Twitter API? Both have different solutions.

AFAIK Twitter requires your password to be sent in plain text but this does not mean it can't be secured.

If the DB is your concern, the twitter module would need to be able to encrypt and decrypt your password. I'm not aware of any PHP implementation of strong reversible (two-way) encryption but you could use the mcrypt extension (http://php.net/mcrypt). There are two problems with this solution. 1) Mcrypt may not be installed on your host. 2) If someone has access to your DB, they might also have access to your scripts and decryption keys which makes encryption pointless.

If you're confident about your DB but paranoid about sending passwords over the Internet then the easiest solution would be to use https://twitter.com for all API requests. A quick grep of the module (6.x-2) includes only http requests, no https. It should be possible to change all http to https in twitter.inc but I haven't tested it. Also, your PHP would need to be compiled with SSL.

I've just put together a few changes to the D6 version that allow twitter to be used in 'no password' mode -- if all you're doing is PULLING tweets from a public account, there will be no need to enter the password.

There's no other alternative, though, for posting TO Twitter -- it requires that the password be sent over the wire, and other than the SSL option mentioned above, it's not really possible to do anything more secure unless the twitte API changes.

There is an extensive discussion on the Twitter API Google Group about passwords that can be read here: http://groups.google.com/group/twitter-development-talk/browse_thread/th...

Twitters solution is OAuth which is going into private beta and will be launched with the next version of their API in the coming months. http://oauth.net

I would personally like to see both: the Twitter account passwords should be stored in encrypted form, if at all possible, and the connection from Drupal to the Twitter service should use SSL when an authenticated transaction is taking place.

Thanks!

To use SSL between your site and twitter, go through the code and change every occurrence of http://twitter... to https://twitter...

If it doesn't work, your PHP may not be compiled with SSL support. You can also use phpinfo() to check for SSL support.

There's no way to encrypt the passwords effectively, though walkah and I have just been accepted into the oAuth beta -- hopefully we'll be able to point to some progress with that shortly, as using oAuth for account setup would eliminate the password storage entirely.

How can anyone seriously make the claim there is no way to encrypt the passwords effectively?

MD5 and SHA both are viable solutions that could EASILY be implimented!!

If I could send a md5/sha hash pwd to Twitter, and on top of that be via https, I would be more than happy with this service.

But SSL or no, I'm not comfortable sending plain text username/passwords to twtitter's API. It's extremely risky....

There is no additional security from implementing an API that accepts pre-hashed passwords. Both plain text and pre-hashed passwords are equally susceptible to replay attacks (assuming non-SSL). The attacker can simply reuse the hashed password as-is. Reversing the hash isn't necessary and therefore the irreversibility of cryptographic hashes is meaningless.

If I could send a md5/sha hash pwd to Twitter, and on top of that be via https, I would be more than happy with this service.

And if Twitter accepted md5 hashes, we'd be ready to rock!

The only solution to this is to roll in OAuth support; it allows a key exchange to be used rather than a username/password pair. That's on the agenda for the next major release, though until Twitter discontinues support for it we will likely continue to include username/password support for folks who don't want the overhead and UI complication of OAuth roundtrips.

In the meantime, don't use the module. There's no way to send anything two Twitter in a more secure form without OAuth.

While I understand that storing and transmitting an encrypted password isn't really an option right now, I do agree with the intent of #5.

Is there a reason the transmission of the password can't be done over a secure channel? Twitter seems to support it.

Hmm, I was wondering about this having checked out the db and seen the plain text passwords. Shame Twitter API authentication is so rubbish! =(

From a storage perspective I s'ppose you *could* write your own encrypt and decrypt functions. I do appreciate it wouldn't be much use, in so far as it would be fairly easily breakable by someone with any sort of serious intent and if they have the db they probably have the PHP too so can just read your decrypt function.

But it would stop anyone casually browsing the database from being able to read passwords (from a site admin/dev perspective, I don't *want* to be exposed to people's passwords - I don't want to know) and it would at least be a small pain for someone who *only* had the db. So in that respect (and since it would only take a few minutes to write) it might be worth it. I am happy to supply a patch to this end, if you guys agree in principle that it would do no harm so might as well exist...? Setting status back to "active" while awaiting a response. Please do set back to "won't fix" if you think this suggestion sucks! I won't take it badly. I'm kinda half wondering if it's worth it anyway. =)

As for the bigger picture, as Twitter usage soars I expect they will be *forced* to make authentication more secure. It's happened with all the big SN sites. They start with fairly crappy security and have to tighten up as they begin to attract the wrong sort of attention. Just sit back and wait, I guess.

I will give shiny new ponies to whoever implements something that I can use to authenticate a drupal site using twitter credentials over OAuth.

With Kittens on?

Ponies, with kitterns on, and maybe even EQUITTY SHAREZ!!

@timmillwood and @NikLP #404470: Authenticate Twitter_Actions.module via OAuth.module 2.x instead of Basic Auth

@everyone else - this was won't fixed in favor of oauth. Please, don't cause needless queue noise. Security by obscurity is useless. If a password is encrypted/decrypted in php then the key must be somewhere on the server which means that anyone able to get a DB is likely to get the key as well -> non-security.

I was talking about oauth... :( I didn't know about the other thread, someone just pointed me here...

@greggles: There would be no "needless queue noise" if there was a bit of communication when the status was set as to exactly why. We're not mind readers. Spiky responses from grumpy maintainers don't make people feel welcome or like helping out. It's especially off-putting when aimed at people who actually *volunteered* to contribute. We all get frustrated with idiots who don't read the issue queue and just post, but don't tar all Drupal.org users with the same brush and assume we're all here to waste your precious time.

So, I'm guessing the oAuth in the 3.x-dev code will replace plaintext passwords? is this possible?

+1

This should help
http://drupal.org/project/encrypt

#15
There is a way around...We could do what LastPass does and use the user's password as key. That is what LastPass does:
(We could use this even for any CCK field)
http://tagfl.com/2009/06/10/help-my-social-account-has-been-hacked/

"Lastpass is a browser plug-in for Firefox and Microsoft browsers. By default, it replaces the insecure (yes, they are) password managers built-in to those browsers. Your passwords are actually saved on the Lastpass servers, freeing you from the possibility of losing all your passwords because of a computer failure. I know what you’re thinking – “But that gives somebody else my information!” Actually, no. Before any of your passwords are sent to Lastpass, they are encrypted with your master password. Lastpass uses 256-bit AES encryption which is as good (or better in most cases) as the federal government uses. Maybe that’s a bad example. How about “Its what geeks use.” There, that’s better."