1

I just saw how to retrieve password from within hook_user_presave(); Not to put a too fine point on it, I believe the use case presented by the OP does not make sense, and the only use case I can see for this question is to set up a phishing site to collect clear text passwords that can then be used too gain access to the same user's account on other social media websites (it is well known that while strongly discouraged, users still reuse account names and passwords on other sites).

The use case presented by the OP is the following:

the client has an external database which it wants to be totally synced with the drupal database, this is the use case.

Having a client that (apperently) wants to have clear text user passwords exported to an external database hardly constitues a use case. We're not even told why this client has his mind set on compromising the user's passwords. Further: This use case is obviously not valid since it misrepresents facts (a less polite person than me would call it a "lie"). If the client want the external database "totally synced with the drupal database", the OP must mirror the hashed password since that is what is retained in the Drupal database, not the clear text one, which Drupal - following good security paractices - do not retain anywhere. Misrepresenting a simple fact about how the Drupal database stores passwords is one the things that makes me seriously doubt the motives of the OP.

While we obviously cannot stop anyone from reading the source code and find out how to do this, I think that Drupal SE should not assist people who request information that compromise the security of their users in locating that information. In other words, I believe that such questions should be closed or deleted.

In other words I want "Questions that request information that compromise security." added to the off-topic list on: https://drupal.stackexchange.com/help/on-topic.

1
  • Note: I upvoted discussion, not the request at the end of it, as I think discussion is a good thing, but with request I disagree.
    – Mołot
    Oct 8, 2013 at 12:11

3 Answers 3

Reset to default
2

If the question was pointing out a security issue present in Drupal core, or any third party module, then it could probably better to delete it until the security issue is not resolved in Drupal or the third-party module. (Notice that moderators should not generally handle NDA agreements, though.)

Since the question is asking how to do something, there isn't any security breach, when the OP is asking something before it gets implemented. That is even more true when the OP is not revealing on which domain the code is deployed (if it is already implemented) or will be deployed (in the case it is still being implemented).

As question asking how to implement something, it is perfectly fine, even more for the fact the answer(s) would point out any security flaw in the code.

Answering such questions correctly could be hard in some cases. I am sure there are users that follows who can give useful tips about how to write the code, even though I would not expect them to actually write any code. There could be an answer pointing out the security flaws, and an answer showing the code the OP could need, though.

2
  • Security issues in Drupal core & modules are already forbidden here under "no bug reports" policy, aren't they? I agree that specific category of bugreports should be treated more harshly than usual ones.
    – Mołot
    Oct 9, 2013 at 7:33
  • By the way, did you really meant to write "on which domain the domain is deployed"?
    – Mołot
    Oct 9, 2013 at 7:34
1

I don't think we can have a blanket rule. Whether something is a security compromise can be quite subjective/context-sensitive.

For example, we have an internal system that pushes passwords to another (secure) internal server when they're added/edited. In that context it's perfectly valid for us to have access to the raw passwords (all users are staff).

If I was having problems implementing that logic I'd consider it reasonable enough to ask a question about it here.

I understand your concerns for user security if someone was to use the technical help we provide for something nefarious, but I think it falls outside our remit to disallow any question whose answer could potentially be used for such a purpose.

To address the edit you made to the question

[I] believe the use case presented by the OP does not make sense, and the only use case I can see for this question is to set up a phishing sit to collect clear text passwords that can then be used too gain access to the same user's account on other social media websites

That's quite a jump to make, considering the OP's comment:

the client has an external database which it wants to be totally synced with the drupal database, this is the use case.

So you've been given a perfectly valid, reasonable use case for asking the question, which negates your accusation at source.

Whether you believe what the OP says or not (as I'm sure you'll tell me you don't) is irrelevant here. We can't make an all-encompassing rule for posts based on one person's perception of data security, and a blind assumption that someone is using the results of a technical exercise for harm.

If you have examples of other questions that you feel 'compromise security', please do provide them. But for a single question which (in my opinion anyway) is, at best, a debatable attempt to compromise security, I can't see there being a site-wide policy made on it.

But as always we'll see what the community think

11
  • As someone working with data security, I think you're dead wrong on this one. Having sensitive data accessible by staff is a serious mistake, In fact, more data breeches are caused by staff than hackers. Sensitive data, such as clear text passwords, should only be accessible if there is a need to know basis. The internal system you describe disclose sensitive information to staff without any need whatsover, which is either stupid or malicious.
    – Free Radical
    Oct 8, 2013 at 7:04
  • 1
    I disagree completely, only I can tell you if those passwords being 'compromised' is a security issue - you don't know the nature of the data. It might be pictures of fish, you don't know. To call it 'stupid or malicious' shows that you don't understand the situation. Which, of course, you couldn't, as you don't know the situation. And that's my point; we can't have a blanket rule for something like this, as your opinion of what is a security risk is different from another person's.
    – Clive Mod
    Oct 8, 2013 at 7:32
  • We clearly have different views on secure system design. My concern is not that some random data (be it pictures of fish or whatever) may be compromised by a data breech. I am worried about personal data, such as the cleartext password may be compromised. That is because personal data by itself is sensitive - irrespective of the context that personal data happens to be used in.
    – Free Radical
    Oct 8, 2013 at 8:21
  • 1
    It's not going to be compromised over an internal SSL to which only a few trusted people have access. No-one said anything about sending passwords as plaintext. That's my entire point - you can't possibly know if something is insecure, or an attempt to breach security, until you have all the details. Digital paranoia is one thing, but you have to have all the facts before you start making assumptions (btw my degree is digital forensics so I speak from a good grounding in digital security)
    – Clive Mod
    Oct 8, 2013 at 8:25
  • You wrote: "it's perfectly valid for us to have access to the raw passwords (all users are staff)". That is a statement of fact (I presume), and my evaluation is based on that statement of fact. I serve on the Privacy Board in Norway. We regularily review data breeches. I've seen some serious data breeches (resulting in identity theft) originating from some programmer that happened to think it was perfectly valid for staff to have access to raw passwords.
    – Free Radical
    Oct 8, 2013 at 8:32
  • 1
    By access I mean access in code, just like the original question is talking about. By staff, I mean technical staff. Programmers. (again, you should stop making assumptions). If we want to add a bit of code to intercept the HTTP post variable that happens to contain the user's raw password, then so be it. It'll live in memory for a little bit, and then be GC'd. How we decide to transport that data around our network has security concerns, sure, but the very exercise of having intercepted the POST is not a security risk. It's not even a security concern, it's the very nature of HTTP
    – Clive Mod
    Oct 8, 2013 at 8:37
  • Finer points of security aside (and actually perhaps I didn't explain myself properly and ended up giving the wrong impression) - the point I'm trying to make is that it's going to be difficult to make any sort of policy based on this. On a case-by-case basis, who's going to decide whether something constitutes enough of a potential breach to warrant immediate closure?
    – Clive Mod
    Oct 8, 2013 at 8:43
  • Clive wrote: "who's going to decide whether something constitutes enough of a potential breach to warrant immediate closure?" I've not said anyting about immediate closure. As to who: I think that the people who today decide on a case-by-case basis whether something is a duplicate, off-topic, unclear, too broad, or opinion based may also vote on security issues. None of the categories listed today as grounds for closure are absolutes. Still, questions get closed, based either upon votes or on immediate moderator action.
    – Free Radical
    Oct 8, 2013 at 8:53
  • 1
    I think this has gone as far as it's going to. We disagree on the point that what you've presented constitutes enough of a security risk to warrant changing our policies. You already have the right to vote to close a question if you disagree with its content, I see no value in adding any text to the help pages on this subject. We're talking about a single, solitary question. Making policies based on a single question isn't a good idea for obvious reasons. As I said, if you can show that this is in some way endemic, then please add links to the other questions
    – Clive Mod
    Oct 8, 2013 at 10:27
  • Voting to close because one disagrees with the contents sounds to me like abuse of voting power. Votes should be grounded in some clear rules regarding what is on/off topic (even if there may be disagreement about whether a specific question falls inside or outside a particular rule). However, I understand that what I propose is not going to happen. Fair enough. I still think the point about this principle was worth raising.
    – Free Radical
    Oct 8, 2013 at 10:35
  • Please don't get me wrong, I have no authority to say "this is not going to happen", and I'm definitely not saying that. My apologies for getting bogged down in the details, I should have kept things more general. My personal opinion is that the general premise of your question wouldn't be the best idea, but if people disagree then it should, and will, shape policies going forward. It's a sensitive subject, and certainly one that's worth discussing. I'm interested to see how other people want to approach this too
    – Clive Mod
    Oct 8, 2013 at 10:41
1

They shouldn't. But more important - there are no, and can't be questions that request information that compromise security. Do you blame the knife, or the hand that holds it? And what makes you able to tell this particular razor will be used to kill instead of shave? The thing is - if something looks dangerous, it hardly ever is per se.

It's worth to note that currently neither What topics can I ask about here? nor What types of questions should I avoid asking? mentions immoral or dangerous as a reason for closure. So at the moment there is no reason within site rules to close them.

I only once have seen a question that I wasn't allowed to answer - OP asked explicitly how to spam his users and it's outlawed in my country (helping with it, too). But again, in other jurisdictions it might be answerable, and mass sending mail is not always a bad thing. Noting all your users about hacker problems seems reasonable, for example, and works just like spamming them. And indeed when I commented about law he answered something like that he is sorry, it was just a manner of speech, and provided valid reason to alert all his users.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .