0

I want to develop a system, something like a comment system for a website, that ensures I know who is posting comments. The content that is exchanged is not valuable and does not need to be encrypted, I just want to have a some reasonable assurance that the person posting the comment is in fact who they say they are. If a post is spam for example, I want to be able to hold the person accountable. At the same time I need the system to be low overhead for users. For example giving them a list of 100 one time phrases that would have to be pasted into an email or onto a website would be acceptable.

I am using node.js and was considering using a diffie-hellman key-exchange.

I know this is fuzzy and I'm not looking for answers per se, but rather a way to think about it, an example or starting point or ... ?

Edit #1 Thanks for the intelligent questions and thoughts.

Use case: Someone physically comes to me and with a thumb drive and I give them a set of one time ciphers. [206,99087,3,etc]. And yes, they have to agree to give me some information and be physically identified. Each time they comment or post (and perhaps post through email) I want one of those ciphers to be sent to me, and they are not reusable. When my application gets an email or a posted comment there is a high degree of certainty about the identity of the person. Little is at stake besides "reputation" so there is little incentive to break into the system, but it shouldn't be trivial.

Accountability means their reputation suffers or they are banned from using the application. Since this is based on their physical person rather than their disposable email person this is sufficient.

  • 2
    So, basically you want basic authentification (username + password), a session cookie so the user are always logged in after the first time and a list of block username to counter spam? – Gudradain Jul 11 '14 at 17:45
  • +1 for session cookie, thanks. I don't want to use passwords, but a sort of one time pad. And maybe not a user name either. And yes to the block, except it is only open to registered users. You have to obtain a key or a cipher book to get in. Your comment helped me think about it more clearly. – user51794 Jul 11 '14 at 18:02
  • "ensures I know who is posting comments" From your question it isn't clear precisely how you're defining a 'identity' and how you're defining 'accountable'. You say you want to know they are who they say they are. Do you actually want to verify IRL names, country of origin, other personal details? Or do you just want to be sure they aren't behind a proxy server? And how 'accountable' do you want them to be? Do you want them to have very little legal deniability about comments made, or do you just want to be able to ban their machines? – Parthian Shot Jul 11 '14 at 19:06
  • The problem is that, in order to identify someone, they have to be willing to give you some information. I suppose you could make giving such information obligate as part of accessing the site at all, but then you have to be sure they aren't lying, which is also difficult to tell. – Parthian Shot Jul 11 '14 at 19:09
  • I suppose for perfect identification what you'd need is a uniquely identifying piece of biometric information which follows a set of constraints which are easy to verify but difficult to fake (i.e. a part of the genome which, when hashed a certain way, always yields the same hash person-to-person, but for which it's difficult to engineer a nonexistant genome fragment that also hashes to the same value) and on top of that you'd need a Trent which holds a copy of all those keys. – Parthian Shot Jul 11 '14 at 19:15
1

Captcha are one of the best way to stop spam bot so you will need them somewhere, but they are a pain for the user. That's why I like when I can authenticate in some way to a system which means that I don't have to answer a captcha everytime.

Session cookie are the way to go to identify a client. He logs in 1 time (or proves that he is not a bot 1 time by answering) a captcha then you give him a session id inside a cookie. Actually there are usually 2 cookies, a session cookie and an authentication cookie. The session cookie is created as soon as the user connect to your site, the authentication is created when he logs in.

For blocking user, you could either block them by IP address, username or by terminating the session (invalidating his session cookie, so he has to reanswer a captcha). But if you chose to do it by username you have to protect the username by a password or anyone could impersonate any username.

Also, if you don't want your user cookie or login information to be stolen (by someone listening on your web traffic), you will need to encrypt all the communication between the client and the server using HTTPS. Otherwise, your cookies and login information are not safe. If an attacker gain access to a cookie he can impersonates that person.

I see 2 alternatives

Alternative 1 : Username + Password

Ask for a unique username, a password and an answer to a captcha when creating the account. After that, the client can simply log in with a username + password. If one account is a spam bot you can either block the username and/or the IP address.

Alternative 2 : Username only

If you don't mind to have duplicate username you can use this way. Simply, ask for a username and the answer to a captcha then gives the user a session cookie to authenticate him afterward. Of course, blocking by username is no use here and you should instead do it by IP address or terminating session.

0

As far as I can tell you don't need anything except the possibility of issuing username/password pairs yourself.

Someone comes to you and proves his identity in any way - the same he had to do for the thumb drive - and you generate and give him a username, a password, and a warning to immediately notify you should they be stolen.

Twist

You can make it so anyone can choose a username and password, and the system displays them as unverified users. When they prove their identity to you, then you flag them as verified users. Less burdensome for you, and people may choose how far to trust unverified users as they wish.

Basically the two systems are perfectly equivalent, except that in the first scenario unverified users just can't post comments :-)

0

A strong authentication mechanism that is easy for the user and provides reasonable assurance would be to stand up a CA that is not trusted by anyone other than your application. Issue each user a certificate with their UPN as the only entry in the SAN extension. Configure your application to authenticate the user via their certificate, and instruct each user to install the certificate in their key-store with an unexportable private key (in Windows CAPI, this is one check-box; in JKS, it is automatic; not sure how FF or Chrome do this on non-Windows platforms).

Since only the holder of the private key can get access, they have proven themself to be the person on-record, or that the person on-record was sloppy with protecting their private key. Revocation means your application can see if someone was disabled very easily, just by OCSP request. The RSA key-pair is stronger than any password, and you don't have to store their private key or any form or derivation of their password, so attacking you does not get an adversary access to your users. Built in expiration dates mean you have an effective enforced password rotation mechanism.

Provide an easy way for a user to request revocation and replacement.

-1

There are a few ways you could identify who is commenting. You can make people link social media accounts, input email addresses, and more.

  • "You can make people link social media accounts," ...which just proves that they can create an account on the given social media site, and doesn't hold them- as an individual- accountable at all. "input email addresses" ...which just proves that they can create an e-mail account, which doesn't hold them as an individual accountable at all. "and more" Option C wins the day! "more" is indeed exactly what you'd need. "less" certainly won't do the trick, and (as we now know) "nothing at all" can no longer be trusted. – Parthian Shot Jul 11 '14 at 20:09
  • No matter what, anyone can fool an identity verification system. For example it is really easy to set up fraudulent paypal accounts using virtual credit cards, and fake names/SSNs/and more. – j_thiel Jul 11 '14 at 22:00
  • "anyone can fool an identity verification system" If you really feel that way, why wasn't that your original answer? It's disingenuous when someone asks "how do I accomplish X" and you- knowing, or believing you know, X is impossible- answer "by doing Y, Z, M, N, etc." – Parthian Shot Jul 12 '14 at 0:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy