Darkorical.9213:

I would love to see a simple bit of info available in the API to tell weather someone has an Authenticator on their account.

After a recent hacked member emptied our guild bank I long for the button from wow that allows you to give permissions based on if a player has two factor or not.

so basically I would like to be able to have a script that those who want guild bank access would provide their API key and it would check to see if they have an authenticator then repeat the check daily and if someone removes it it sends me an email to let me know to remove their bank access.

Ruhrpottpatriot.7293:

There is a great deal of security issues in your proposal.
1. You are asking the members to give out their api key. Never do that. Granted api keys are not passwords, but they should be kept a secret nonetheless. An exposed api key can still be harmful.
Consider the following: You have a website where the user can input his api key and get informations about his account. Now your website is hacked and the hacker gets hold of the api key (leaving the problem of unencrypted private info out of this). He now can systematically check which account has an authenticator, and which not. He will then hack the ones without additional security.

Yes this could happen if he got hold of the passwords too, but we all know you should never use the same password twice. But even if the users have (which is almost every time the case), you are not making it easier for the hacker, in the case of the api key, you actually do.

2. Providing such info via a public api is a no go, for obvious reasons.

Yes, this is a problem for the guild overall, but it is a problem you have to live with. There are best practices for such occasions, such as giving guild banks access only to trusted members or let your members know why an authenticator is better.

Lawton Campbell.8517:

1. You are asking the members to give out their api key. Never do that. Granted api keys are not passwords, but they should be kept a secret nonetheless. An exposed api key can still be harmful.

What? No, that’s the point of an API key: to give them to people who you trust with the information (either directly or indirectly, e.g. by giving them to an application). You probably don’t want to go posting them publically, but they’re not very useful if you keep them secret.

On-topic: I know it’d be useful for you, but I’m almost certainly not going to expose authenticator status.

Ruhrpottpatriot.7293:

What? No, that’s the point of an API key: to give them to people who you trust with the information (either directly or indirectly, e.g. by giving them to an application). You probably don’t want to go posting them publically, but they’re not very useful if you keep them secret.

I think I misspelled my point. You are right. You want to give out the api key to people you trust, but not publicly. I still think that an information that is a potential security risk should not be exposed by an api, that is (potentially) open to a wide group of people.

Lawton Campbell.8517:

I think I misspelled my point. You are right. You want to give out the api key to people you trust, but not publicly. I still think that an information that is a potential security risk should not be exposed by an api, that is (potentially) open to a wide group of people.

Yeah, I think we’re in agreement.

Anyway, I passed the idea to optionally restrict access to the guild banks to members that have TOTP enabled to the guys who work on the guild stuff — I think it would be a nice feature to have, the API just isn’t the right place for it.

Darkorical.9213:

I know this conversation has carried on without me a bit but I shall none the less respond to all aspects

There is a great deal of security issues in your proposal.
1. You are asking the members to give out their api key. Never do that. Granted api keys are not passwords, but they should be kept a secret nonetheless. An exposed api key can still be harmful.
Consider the following: You have a website where the user can input his api key and get informations about his account. Now your website is hacked and the hacker gets hold of the api key (leaving the problem of unencrypted private info out of this). He now can systematically check which account has an authenticator, and which not. He will then hack the ones without additional security.

As Lawton responded that is the purpose of the API, however that being said when I build scripts I go to great lengths to protect data and as such any stored API would be encrypted itself. and more than likely I would program such a system to not actually store anything but the encrypted API so that if any api was found connected to an account without said protection then they system would use the api to collect character info and send only me an email. Having the system built this way would make any compromised data virtually useless to anyone.

2. Providing such info via a public api is a no go, for obvious reasons.

Actually I fail to see what would be so obvious about this.
First of all since we have the ability to choose what is exposed by what API Key then it comes back to trusting who you give it to.

But beyond that the info of weather or not a person has an authenticator wold not be really that helpful to hackers. If you look at how most hacks occur, many times it is achieved by fishing for login info via scam mails. This method provides them with login info but not character info or account name. These are the two things they would need to compare against API info to be able to check if there is an authenticator.

Other hacking methods include the hacker getting your email login info and discovering that you have a game account then going to the game and requesting a password change once the password change email is sent they go to your email click the change password link. and enter a new password for you. Then go get your stuff.
Now last I knew in order to change your password in GW2 you needed to use a ticket and the method of verifying your ownership of the account included display name character names or list of guilds. ALL of those things are already in the API.

Now if there exists a hacking method that would provide easily cross referenced data that they could use against a database of API Keys to eliminate accounts with authenticators from the list. Why would they spend the time or processing power to check for it when that same time and check could be spent logging in and since the goal us usaly to get in and out with the hacked accounts goods as quickly as possible it seems to me that it would simply be a waste of time.

Also I for one have never kept the fact that I use two factor authentication a secret, in fact I tell everyone I talk to about it in an attempt to persuade them to make use of it as well.

Yes, this is a problem for the guild overall, but it is a problem you have to live with. There are best practices for such occasions, such as giving guild banks access only to trusted members or let your members know why an authenticator is better.

I have seem guild banks raided by hacked Guild leaders. My own guild was recently raided by a hacked officer who has been a long standing trusted member who happened to mess up and fell prey to a fishing email.

Anyway, I passed the idea to optionally restrict access to the guild banks to members that have TOTP enabled to the guys who work on the guild stuff — I think it would be a nice feature to have, the API just isn’t the right place for it.

All previous comments aside I respect your decision if in fact it is final. I also thank you for passing the suggestion on as while building something via API access would solve the problem for me personally I think globally for all guilds a simple button offering to restrict all access to the bank or individual tabs in it to those with authenticators. would be a much better solution and greatly lower the incidences of guild bank pillaging. As well as adding in daily limits to withdraws such as no more than 5 items per day for this rank and separating gold withdraws from bank access and allowing limits on that as well.