New Provider: FirstEnergy and subsidiaries

[micle546]

FirstEnergy and it's subsidiaries are using opower. Creating this issue to support the addition of FirstEnergy.

I've done some of the initial work to support this. Will continue over the course of the next few days

login page - https://www.firstenergycorp.com/content/customer/log_in.html
or
https://www.firstenergycorp.com/log_in.fecorplogin.html

https://www.firstenergycorp.com/my_account/analyze-usage.html

First Energy: Ohio Edison uses feoe.opower.com

Others appear to be: (need verified)
(?) https://fepa.opower.com/
MetEd(?) - https://feme.opower.com/
PennPower (?) - https://fepp.opower.com/
(?) - https://fepn.opower.com/
ToledoEdison (?) - https://fete.opower.com/

[micle546]

I think it's returned as an oauth bearer token? (not a webdev)
POST to https://www.firstenergycorp.com/log_in.fecorplogin.html

login:<USERNAME>
password:<PASSWORD>

Response from https://www.firstenergycorp.com/my_account/analyze-usage.html?cache=no

<script>
var currentWidgetOpco = 'FEOE';

window.addEventListener('opower:unauthorized', function(event) {
  var authorize = event.detail.authorize;
  var authorization = {
   accessToken: '<TOKEN>'
  }
  authorize(null, authorization); // Do not call if user is logged out
});

Used with GET

authorization: Bearer <TOKEN>
opower-selected-entities: ["urn:opower:customer:uuid:<UUID>"]

[micle546]

If I POST the login and passwd to the log_in.html page, I should just be able to GET the analyze-usage.html page to pull the bearer token after some specified waiting period for processing, right?

I'm mostly stumbling in the dark here.

Done some python, but never any web stuff, particularly with async/await threading.

[nlowe]

I spent some time trying to get this working tonight and hit a roadblock. When making a POST to https://www.firstenergycorp.com/log_in.fecorplogin.html, something is injecting these additional values on the form data:

r8loFrsvDB-a
r8loFrsvDB-b
r8loFrsvDB-c
r8loFrsvDB-d
r8loFrsvDB-f
r8loFrsvDB-z

r8loFrsvDB-z is the only one that doesn't seem to change, it is always q. The rest are fairly large and look like base64 data that has been encrypted. It looks like there are two WebAssembly processes running on the login page as well which may be where this is coming from.

I'm guessing this is some sort of WAF or security proxy, because if these fields in the form are not correct, the login post responds in ~58ms, while a successful request takes about a second.

It looks like they can be re-used, but I'm not sure for how long or how secret they are.

[nlowe]

Yeah if I disable javascript entirely with uBlock I get the same generic 403.

[nlowe]

First energy had this notice on their login screen now. I'll check back after this goes live to see if this changes anything that might help here

Login Updates Coming Soon for Online Accounts

As part of our commitment to protecting your personal information, we are upgrading the login process on our website to provide additional account security. This update will require that you change the password for your online account. Please be assured that this is part of a system upgrade and not in response to any security incident or threat.

After the update is implemented the evening of March 7, you will be required to create a new password the next time you log into your account. Changing your password will be required, even if you recently changed it. You will also have the option to set up multi-factor authentication (MFA) to add another layer of security to your account.

We appreciate your understanding and cooperation. For more details and instructions on how to change your password, view our Password Change FAQs.

[nlowe]

Ok, I had some time to come back to this. The flow is a bit different but those same values are getting added as headers this time on a request that is 403'ing with an empty response and no useful headers in the reply. I still see two webassembly processes running.

Also, it looks like I'm not the first person to hit this, see #15, #19, and #31