AOPA forums down?

flyingcheesehead

Touchdown! Greaser!
Joined
Feb 23, 2005
Messages
24,260
Location
UQACY, WI
Display Name

Display name:
iMooniac
Hey folks,

I'm trying to make a rare trip to the red board, and I've discovered that in at least three different browsers, I'm unable to get in - There's a redirect loop happening. Is anyone else experiencing this?
 
AOPA's been FUBAR all day - they were supposedly changing databases or something for the main site & account info. None of that was working this AM (you couldn't even get in to become a member or renew.... ). My guess is that they're working the revenue systems before stuff like the red board.
 
Today is the first day "live" on their new membership tracking system and it has been a nightmare from those who've had contact with them today. Expect some time for them to sort this out.
 
I had no luck either. I find it totally stupid that the "new, improved, better for you" web sites always take weeks to function almost as good as the old operation. :rolleyes2:

Cheers
 
So, didn't they FUBAR the release of their latest flight planner too? (I don't know for sure because I've never liked any of their flight planning products.)

But if so...

...what can they do w/o screwing it up?

They remind me of government more every day. Screw up anything they touch.
 
Based on what I see of their technology and the way they've been running things they need to boot whomever has been in charge of making their technology decisions and find someone that knows how to do things right.
 
They are an organization with an organizations errors and biases - they cannot do what needs to be done because a committee has to first convince the CEO to create another committee and another bureaucracy to fix whatever the first problem was . . .

they rarely take their members advice if that advice is against what is good for them . . . cie la vie.
 
They use a "service" from the US post office to get change of address information. They changed my address when my son (same first and last name, different middle name/initial) bought a house earlier this year and moved out of ours. The first I knew of it was when my AOPA Pilot mag arrived in his mailbox. I contacted them to see what was going on and suggested that they add my middle initial to their records so this didn't happen again. Then I changed my address in their database. It will be interesting to see if they mess this up again.
 
013.jpg
 
Based on what I see of their technology and the way they've been running things they need to boot whomever has been in charge of making their technology decisions and find someone that knows how to do things right.

Can't do that...the guy that runs their tech department is too busy out fueling the AOPA jet for Craig to take a flight!!

:D

Mike
 
Based on what I see of their technology and the way they've been running things they need to boot whomever has been in charge of making their technology decisions and find someone that knows how to do things right.
THIS!

But Jesse, that would mean they'd have to PAY someone to do this......
 
Based on what I see of their technology and the way they've been running things they need to boot whomever has been in charge of making their technology decisions and find someone that knows how to do things right.


It always amazes me how cheap some companies try to get with their customer facing product. Other than the rare call in, the website is THE way to interact with AOPA. It should be considered mission critical for them.
 
Based on what I see of their technology and the way they've been running things they need to boot whomever has been in charge of making their technology decisions and find someone that knows how to do things right.

You should offer your services. I am not being facetious, you have participated in running an aviation website with few if any blemishes. I can't imagine anyone with more relevant job experience.
 
Still down this morning. What a bunch of moroons, as Bugs Bunny would say.

Cheers
 
"MEMBER ALERT: AOPA has transitioned to a new database and member management system. Web login passwords are now CASE SENSITIVE. Additionally, if you would like to sign up or upgrade Pilot Protection Services, please call Member Services at 1-800-872-2672 as the online applications
are temporarily unavailable. Finally, the member forums are down temporarily. We are attempting to bring them back online. Learn more here about member services during the transition. Thank you for your patience."
 
You should offer your services. I am not being facetious, you have participated in running an aviation website with few if any blemishes. I can't imagine anyone with more relevant job experience.

Good people are one variable in the equation. Adequate resources made available to them is another. As an old professor might have said "Both are necessary, but neither is sufficient."
 
You should offer your services. I am not being facetious, you have participated in running an aviation website with few if any blemishes. I can't imagine anyone with more relevant job experience.

Would that mean if the admin of the blue board stated admin'ing the red board... we'ed have another purple board? :rolleyes:
 
It would be excusable if they were running on a shoestring budget. But, they've got millions in the bank, and exec salaries are in the stratosphere.

This migration of the DB is a big job, but it can be done without taking a site down. It does cost more money to replicate and have a fully functional dev site with testing and a backout plan, but it can be done. Etrade is a good example. They have an impressive uptime record because being down costs them up to a million dollars a minute(or so).

They just didn't want to spend the money a function of their size should spend, they went cheap. Also, with a decent network design, it doesn't take that much more to do it right if people are competent.
 
"MEMBER ALERT: AOPA has transitioned to a new database and member management system. Web login passwords are now CASE SENSITIVE. Additionally, if you would like to sign up or upgrade Pilot Protection Services, please call Member Services at 1-800-872-2672 as the online applications
are temporarily unavailable. Finally, the member forums are down temporarily. We are attempting to bring them back online. Learn more here about member services during the transition. Thank you for your patience."

That sentence is highly concerning. The only way they could take previously non-case sensitive passwords and suddenly make them case-sensitive is if they're storing the passwords. They should *NOT* be storing passwords as it's a major security risk and big disservice to their members. That alone is enough to make me not do anything with their website again.
 
That sentence is highly concerning. The only way they could take previously non-case sensitive passwords and suddenly make them case-sensitive is if they're storing the passwords. They should *NOT* be storing passwords as it's a major security risk and big disservice to their members. That alone is enough to make me not do anything with their website again.
JOOC, where should passwords be stored? Most places needing a password, I can log in from any computer, so I thought the password must be stored in some fashion on the host, even if it is encrypted somehow. What don't I understand?
 
JOOC, where should passwords be stored? Most places needing a password, I can log in from any computer, so I thought the password must be stored in some fashion on the host, even if it is encrypted somehow. What don't I understand?

Responsible practice is that the system (whether it be a web board, a store, whatever) creates a "hash" -- a representation of the password created by application of a conversion algorithm to the actual password.

The hash confirms that the password entered by the user is correct, while not allowing for the actual password itself to be retrieved or decoded.

I would trust Jesse with my passwords; but not most board administrators, and in any event, there's always the "Bus Clause"; as in, "what if you get hit by a bus?" Bottom line: no system administrator or online store should have clear text access to your password, or the ability to derive it easily.
 
JOOC, where should passwords be stored? Most places needing a password, I can log in from any computer, so I thought the password must be stored in some fashion on the host, even if it is encrypted somehow. What don't I understand?
It's all about hashing passwords. The following Wikipedia article explains it with detail
http://en.wikipedia.org/wiki/Cryptographic_hash_function

A super-over-simplified-but-easy-to-understand version is something like this:

Imagine your password is "abc". Now we assign a number to every letter in the alphabet. a=1, b=2, c=3, etc.

We could take the password of "abc" and sum each value and come up with 1 +2 + 3 = 6.

Instead of storing "abc" we'd simply store 6.

If you tried to give us "abcd" that would equal out to 10 which wouldn't work.

Good password hashing schemes are of course much stronger and much harder to break but the principle is similar. These days you generally should be using something like bcrypt with the appropriate work factor:
http://codahale.com/how-to-safely-store-a-password/

At the end of the day if someone stores your database all they get are the hashes and if things are well done it's incredibly difficult to figure out passwords that equate to those hashes. Since people tend to reuse passwords so much across websites this is pretty important.

There have been major security incidents where a database of e-mail addresses and passwords has been leaked. From there "hackers" can use that data to log into other websites.

Back to the AOPA issue. If you're hashing passwords you have no idea what the original password is therefore there is no possible way for you to suddenly go back and change your password case-sensitivity scheme.
 
That sentence is highly concerning. The only way they could take previously non-case sensitive passwords and suddenly make them case-sensitive is if they're storing the passwords. They should *NOT* be storing passwords as it's a major security risk and big disservice to their members. That alone is enough to make me not do anything with their website again.

No, there is another way.

They could have formerly downcased the passwords prior to encryption. But to make the change means they would have had to store the encrypted passwords both in downcased and original form, which seems unlikely.

I've seen engineers go through hoops to try to make things case insensitive, where it really shouldn't have been necessary since keyboards started coming with shift keys, somewhere around 1975.
 
Yeah, I wasn't going to say it, but the case insensitivity part isn't very hard at all. It's just a function which returns lc for any lc and lc for any UC then sends it on to the firewall server. It's usually a single pass, but it can be made as a double pass as well.

Frex: a = 1, b = 2, c = 3; A = 1, B = 2, C = 3 := apply salt value then hash.

For many low security applications it's kinda common.
 
No, there is another way.

They could have formerly downcased the passwords prior to encryption. But to make the change means they would have had to store the encrypted passwords both in downcased and original form, which seems unlikely.

I've seen engineers go through hoops to try to make things case insensitive, where it really shouldn't have been necessary since keyboards started coming with shift keys, somewhere around 1975.

Yeah, I wasn't going to say it, but the case insensitivity part isn't very hard at all. It's just a function which returns lc for any lc and lc for any UC then sends it on to the firewall server. It's usually a single pass, but it can be made as a double pass as well.

Frex: a = 1, b = 2, c = 3; A = 1, B = 2, C = 3 := apply salt value then hash.

For many low security applications it's kinda common.
No that doesn't work at all. If they formerly down-cased the passwords and if the passwords were properly hashed they would have to instead say:
"We were stupid and formerly downcased all your passwords. But now we allow case-sensitive passwords so if your password previously has upper case letters you must now type it as lower-case". Which you'd never write. Instead you'd just make all future passwords be proper. So since they wrote what they wrote, what they're doing or what they were doing is incredibly clear.

Unless as MAK says, they stored both, but that's extremely extremely unlikely.
 
It does work, and I've done it in a prev life. If the function is removed before the hash, then no longer case insensitive. Someone who used to type; 'PaSsWoRd' got changed to 'password' and then the salt and hash would work. Sometimes the UC to lc was combined into the salt function. Now, after the change the existing hash would be applied to 'PaSsWoRd' and then hashed and would fail. Not hard at all. Not very secure, and certainly doesn't meet current crypto standards but hey - it's just AOPA...
 
and, its down again . ..

When I last dealt with systems migration . .. I insisted that the company that was going to create the new system get it up and running - and run in parallel for a week before we migrated. I promise you that every single possible bug was uncovered in that week and when the system went online to the firm not a single person noticed anything other than the new layout. . . .
 
Why would anyone want to hack my AOPA password, and why should I care if they do? It seems like an application where the downside of a security breach doesn't amount to much.
 
Do you use the same email address and password on any other websites? Are they equally unimportant?

I've never checked, but does AOPA store credit card info? For example, can you modify your membership, or buy any additional services, either by paying with the same card you renewed your mebership with last time (stored payment info) or on a "send me a bill" term?
 
Actually, the way I'd handle the switch is a DB flag that says if the password was changed since the hash was imported(assuming it was flattened to lowercase before hashing). If not changed lc(input) before checking the hash, else after it's been changed then compare it directly. Of course, it's 50x more likely they were just storing the passwords in plaintext.
 
Do you use the same email address and password on any other websites? Are they equally unimportant?

The solution to that is to have unique strong passwords for anything that matters. I'm just trying to figure out whether the AOPA site is in that category.

I've never checked, but does AOPA store credit card info? For example, can you modify your membership, or buy any additional services, either by paying with the same card you renewed your mebership with last time (stored payment info) or on a "send me a bill" term?

AOPA does have an option to automatically charge dues to your credit card each year. I can't tell whether cracking the password would allow access to the credit card number on file, because right now, when I click on "My Account," it takes me to the AOPA Forum! :rofl:
 
By the way, the forum is back up again, but slow.
 
Why would anyone want to hack my AOPA password, and why should I care if they do? It seems like an application where the downside of a security breach doesn't amount to much.

The problem is that the vast majority of users reuse their password on other websites. This is proven time after time again when breaches occur and you need to expect that of your users and protect their data. It's what responsible companies do.
 
It's all about hashing passwords. The following Wikipedia article explains it with detail
http://en.wikipedia.org/wiki/Cryptographic_hash_function

<SNIP>



Back to the AOPA issue. If you're hashing passwords you have no idea what the original password is therefore there is no possible way for you to suddenly go back and change your password case-sensitivity scheme.

Jesse, thanks for the explanation. I will continue to use AOPA since, if someone cracked my account, there are few consequences for me that really matter. I appreciate the warning because I know not to leave any important information there.
 
It's amateur hour over there... Who wants to bet their head of IT makes north of $100k?
 
No that doesn't work at all. If they formerly down-cased the passwords and if the passwords were properly hashed they would have to instead say:
"We were stupid and formerly downcased all your passwords. But now we allow case-sensitive passwords so if your password previously has upper case letters you must now type it as lower-case". Which you'd never write. Instead you'd just make all future passwords be proper. So since they wrote what they wrote, what they're doing or what they were doing is incredibly clear.

Unless as MAK says, they stored both, but that's extremely extremely unlikely.

Well...

If they wanted to be sneaky about it, they could always lie. They could make believe that they never downcased, instruct the user to enter the case-sensitive password, check the hash of the downcased version of the case-sensitive version against the stored hash, and then update the db using the case-sensitive password as the new password.

So basically they would strtolower (assuming PHP) whatever the user enters, check it against the stored hash, and then update the DB using the new, case-sensitive password if the hash matches. The password might or might not use the cases that the user specified at registration time, but who cares? Few (if any) users would ever be the wiser, so if all the admins wanted to do was save face, that would be accomplished.

-Rich
 
Last edited:
Back
Top