Closed (won't fix)
Project:
Drupal core
Version:
8.0.x-dev
Component:
user.module
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
9 Nov 2010 at 11:33 UTC
Updated:
29 Jul 2014 at 19:10 UTC
Jump to comment: Most recent
Comments
Comment #1
gfxguru commentedActually this may be considered a feature request to some. I think if we promote it as is, within it's current state, it would speak louder if we consider others security.
Comment #2
alexweber commentedI've been watching the issue queue for a while and this one caught my eye. Angel Marin has a great SHA256 implementation in javascript which might be worth taking a look at.
In case anyone finds it useful, last year I ported it to jQuery as a plugin.
Comment #3
int commentedFirst, isn't a BUG it's my design.
Second, is too late to add new feature.
Comment #4
marcvangendI don't see how this can be anything else than a feature request.
Comment #5
gfxguru commentedYou ported this too jquery? you have got to be kidding me!. I've found another one but this is a gem!! Yes, ... Angel did a very nice piece of magic with this one. I've gotta try this one. What I'd like to know is can we include this or this feature within core?
Comment #6
int commentedmaybe in Drupal 8
Comment #7
gfxguru commentedA feature request unless you look at the majority of other packages and exactly what they are doing!
I think it speaks louder when you can default from the norm and include others security regardless.
I'd really like to know from others what you think. Should this be a feature or a core capability?
Comment #8
int commentedSTOP CHANGE TO Drupal 7.
Comment #9
gfxguru commentedDrupal 7 has been in development for how long?, I don't mean to offend truly I don't.. I'm just thinking about the majority of individuals that won't know better. I'm also thinking about the servers that others host for individuals that don't know any better. Think about it!
Comment #10
damien tournoud commentedThis has absolutely zero value. If you want to protect the confidentiality of the password, use SSL.
Comment #11
catchI'm changing this back to 8.x, code freeze was a year ago. It's precisely the length of the Drupal 7 release cycle which makes us extremely reluctant to make any major changes at this stage.
If this was to get into Drupal 8 in such a way as not to break backwards compatibility, then there's some possibility of a backport to Drupal 7 for security hardening, would depend on the implementation, how easy it was to do from contrib, whether Dries/webchick thought it was worth backporting etc. etc. Nothing stops you working on a patch, getting it reviewed etc., but please do not abuse the issue priorities and statuses simply to draw attention to your pet issue.
Comment #12
catchOr that.
Comment #13
gfxguru commentedTrue to a certain degree but SSL is costly actually if you've ever run a site with a lot of traffic and if you don't block the bots route you'll get duplicate content with SSL on all your external pages.
Comment #14
oriol_e9gIMO javascript encriptation is not a solution, we need to provide an alternative to satisfy the accessibility standards.
If you want a more secure login enable https for the login page and don't use the login block, or enable https fer all the pages that appear the login block, this is the D7 solution, for other solutions, D8.
Comment #15
int commented@Damien Tournoud, @oriol_e9g we can use one-time password algorithm. So that the password is impossibly to discovery.
See it here: http://drupal.org/node/965734#comment-3685904
Comment #16
gfxguru commentedOuch ok that hurt. Actually no pet project at all, I just think IMO that would only save everyone a bunch of trouble in the long run.
Comment #17
damien tournoud commentedAgain. Zero added value. We don't do security theater here.
Comment #18
gfxguru commentedThen we will just disagree. I can think of at least 10 ways this would add value. Not to mention the number one thing. Show me a site that is using a Drupal 7 and I'll show you how to hack into it.... That's enough right there.
Comment #19
int commented@gfxguru can you hack the drupal.org :)
If you want that yours site don't send the text-plan password to the server, and you don't want to use SSL.
You have the http://drupal.org/project/safer_login module.
Comment #20
gfxguru commentedThe more I think about this the more it's really started to bother me. And you've closed the request and stated won't fix...
Comment #21
Everett Zufelt commentedI don't see too much utility in this, as was mentioned this only works for UAs that support Javascript (not that this is an actual accessibility issue). Nevertheless @Webchick stated clearly that anything that was not fixed / marked critical in D6 isn't critical in D7, and I expect the same is true for D8.
SSL doesn't need to be costly, using an expensive SSL cert is costly, using a cheap SSL cert is cheap.
Comment #22
gfxguru commentedSSL is costly and it has nothing to do with the cost of the certificate. Well actually it does due in part to the strength of the encryption but the cost come in the amount of connections all via SSL. A server with heavy traffic will bottleneck first trying to encrypt the transactions. Here's where another box that the will off load such comes in handy, another story.. .
I'm just talking about the actually password here for a login. We can encrypt this and pass this to the server without SSL and without encrypting the complete page, or any other page. This would almost make a site at least 100% more secure, maybe not fully secure, but for sure... a whole lot more " And add a little promotional point here too!" How many other open source platforms are concerned with users security?
Here's something else to think about... Anyone that has ever hosted a site for a client! What happens if this clients is running in a shared environment, now what happens if one client in this shared environment is compromised, well depending on the environment you could. 1) compromise other sites/databases on the same server or 2) compromise the complete server and everything connected.
Comment #23
int commented@gfxguru, stop change the priority all the time.
If you want what you says, you can use the http://drupal.org/project/safer_login module.
But, really don't protect more your site.
Does not protect against:
- phishing / MITM
- "Capture the SessionID" (!)
Really only protected to know you password. So, only protected others https sites that you are using the same password.
If the user does not have JavaScript enabled, this hashing/encryption is not possibly, you have to use the drupal way.
Comment #24
Everett Zufelt commentedThis is not critical. You may think it is critical, and I respect that. However, we have rules in this community, and this is * not * a critical issue.
Comment #25
alexweber commentedAfter going through the discussion I have to agree that this does qualify as a new feature and would only really delay Drupal 7 even further.
However, (and on a tangent here) regarding the utility of client-side encryption, I'm convinced it adds great value as if you're not sending plain text passwords (or usernames for that matter) you greatly reduce the risk of getting hacked. That said, alone it does little but should be used in conjunction with best practices.
Cheers!
Comment #26
gfxguru commentedThe more I think about this issue the more it's really starting to get to me. I can't believe we are on version 7 (starting version 8) and we can't do this yet? I mean what is the point in releasing something THAT YOU KNOW IS INSECURE. Your putting a lot of people at unnecessary risk and because of what? To reach some type of deadline. "WHAT" how long has Drupal 7 been in development? Or is it for other reasons? What to make sure people that get their sites hacked come back and pay someone to fix it?
Again I will wait because this is only one security issue. And if someone has a default Drupal 7 site and would like to know just how vulnerable the site is. Just ask around, You or I could attach any sniffer to the IP address associated with your website and record all transmissions accross it. It's a matter of only waiting until someone logs in and you have their LOGIN AND PASSWORD...
And to who ever closed my ticked!. Please don't close the tickets I have open if they have not been addressed. I understand why it was moved, fine, just please don't cause any further incidents because someone doesn't see things the way you do. You manage your security, I'll take care of mine.
I do not suggest anyone install Drupal 7 on a production server, even Drupal 6 "without" securing it!. You are asking for trouble. I'm going to publish an article about this and see what others think. I think it would be a grave mistake to release "version 7 of Drupal" without addressing this.
Comment #27
int commented@gfxguru, are you ignoring me?
Facts:
1) Your site is only secure if you uses HTTPS.
2) Hashing/encryption the password/login form will not make your site safer.
3) If you want to use Hashing/encryption login, you have one module for that.
What you don't understand?
Comment #28
heine commentedYour proposed "encryption" is WHAT WE KNOW IS INSECURE.
O NOZ!
Instead of waiting for the username + pwd, simply capture and reuse the session id. Or, why not make a phishing site and hope an unsuspecting victim enters his pwd on that site?
Comment #29
marcvangend@gfxguru:
There is no "deadline" for D7. If you don't care about finishing D7 you're out of luck, because tens of thousands of users do. You can start your own fork and make it a perpetual beta.
If you cannot handle your issue being closed, don't start one. Closing issues as "won't fix" is part of the Drupal development workflow. It's nothing personal and this issue would not be the first.
There is nothing wrong with starting your idea as a contributed module. You're obviously running into a brick wall here. If you still believe that your method of securing the login is an improvement, do yourself a favor and don't start banging your head against the wall. Instead, but write a module and prove us that you're right. Many core improvements have started this way.
Comment #30
gfxguru commentedYou're telling me that encrypting the password and passing it from the browser to the server is insecure?
Comment #31
gfxguru commentedI don't understand why so many people are against me on this. To constantly say NO, NO, we won't or can't do that..... And I thought at least a couple people here would understand.
Comment #32
gfxguru commentedPerpetual beta, that's funny. Here I thought you were just trying to be funny, but I understand now.
Comment #33
gfxguru commentedHeine, your right. There are many other way we could hack a Drupal site. I'm just trying to gain some assistance in securing the one main area that would secure the majority of the site. You are correct there are probably more the a handful of ways into Drupal. Do you really want me and others to post those here?
The thing I don't understand is you are the team leader for the Drupal security team? And why do you think that I can't sniff out the users login and password from a default drupal 7 install.
Comment #34
gfxguru commentedI think everyone need to take a look at this. You're right I'm not the only one! There are a bunch of others asking for security issues to considered and resolved. Most of those too are being "Closed (Won't Fix)"
http://drupal.org/project/issues/drupal?text=security&status=5&prioritie...
Comment #35
gregglesHi gfxguru,
I think the reason a lot of people are opposed to this is that it doesn't provide much additional protection. It's true that something like this obscures the password to make it harder to read but ultimately if you don't use SSL then the sessionID is passed back and forth to the server in the clear and can also be hijacked allowing someone basically the same value as stealing the password.
Then we have to consider the potential downsides to adding something like this. Ever additional feature we add creates an overhead that has to be maintained with the core codebase. If the form system is changed then this client-side encryption would need to be changed to work with the new form system. Maybe people who cared enough to add the client-side encryption would not be around to help with that upgrade so someone else has to do it. Drupal is constantly adding and shedding features, but the shedding is quite hard so when new features are added people have to be sure that they are useful for the broad majority of sites running Drupal.
As others have indicated, this is already possible in a contributed module - http://drupal.org/project/safer_login - and anyone who feels that this provides benefit should use that module. As we can see, that module has only 94 sites using it while Drupal core is used on hundreds of thousands of sites. Something that is relatively unpopular is a great example of a feature that belongs as a contributed module and should not be part of core.
I'm marking this by design for now. We've already had three members of the security team (Damien Tournoud, Catch, and Heine) comment on this issue stating that it doesn't provide enough value to be ready for core which makes me the fourth to affirm that statement.
I'm marking this as won't fix for now. I suggest that anyone who is in favor of this feature work to improve the safer_login module and make it more popular. If in the future the use of that module becomes much more popular then we could reconsider the idea for inclusion in core.
Comment #36
gfxguru commentedI understand that, and thank you for taking the time to post. You have shed a much broader light on the subject that I truly didn't realize. I honestly couldn't understand why ppl seemed to be getting hostile at the thought, but I believe I understand now. Sorry I'm really still a Drupal newbie I guess. I've been more of a Drupal stalker I guess you could say over the past 5 years, learning and trying different things. I do love Drupal and am addicted so don't ever think I'm putting Drupal down!!! I just see so much more potential in Drupal, I truly do. I mean I've been working with Open Source packages since the dawn of the term, but this package is truly the most flexible that I've ever tried to come to an understand with. See I'm a skeptical about anyone that tell's me that they really know Drupal, and I believe that anyone says that, truly doesn't know Drupal, in otherwords most people don't know where it's come from, how it's evolved, all the different area it's being used, and most of all - "The complexities of the Drupal evolution built upon PHP that has also evolved by leaps and bounds since Drupal's inception. This is in where the loop holes and cavities can multiply and create not only a huge amount of in's and out's to consider but also burden one's inability to harden and close some of those avenues.
I truly am addicted to Drupal, why well the numerous ways every should know of course, but I began to wonder sometimes if this addiction is going to be the end of me... It's funny actually, It's almost as if one man search for significance leads him astray from the holy grail. ;) I'm only kidding of course. It's just that feel so damn overwhelmed sometimes when you truly have to consider that amount of ways a user, person, browser and bot can all travel... Ok maybe I'm just rambling a bit and looking for some answers here. I don't mean to offend anyone truly I don't. I just wish there was a way we could harden the flow of users though a Drupal system. Now granted that it's capabilities make that innumerable I understand, I just wish there was a better way of organizing and approaching this situation a little differently. I'm still looking and if anyone here has felt my pain please, please, share with me and the others, what is working for you..Because I along with quite a few others, would love to know.
oh yea, just a little thought: Wasn't PHP "Personal Home Pages" when Drupal came out?
Comment #37
owen barton commentedIn addition to the attacks on the session ID, if you are on a hostile connection a JavaScript password encryption based approach would also vulnerable to Phishing-style attacks, where they redirect the request (via DNS or IP) at a mirror/proxy version of the site and take over that way. This kind of attack is what the SSL certificate can protect against. Also, unless coded very carefully many JavaScript password encryption approaches would be vulnerable to replay attacks (I haven't looked at the contrib module in this respect). Each of those pieces can certainly be strengthened individually, but SSL remains the tool to use if security is important to you (and even SSL is fallible to misconfiguration and user mis-identification).