Updates on the security changes (how to keep your client working!)

[mark]

Hi all,

I've got a few updates from the recent post on security changes. First, thanks everybody for the thoughts! Loved it. :)

So the main changes:

• After consultation with some actual experts in the security space, I've added a pepper phase to the authentication storage. The TL;DR here is that we will be symmetrically encrypting the hashes before we store them in the database.

  The reason to do this is that it means a database breach (if one were to occur) would not provide the attacker with any useful data. In order to even get the hashes to start attacking them, the attacker would have to mount a second successful attack in order to exfiltrate the encryption key (which is not stored in the database at all).

  While in practice, the bcrypt hashes are probably all anybody really needs, it's very low cost for us to add this additional measure to the system. For the technically curious, we are using AES-256 encryption on our web servers and we have the ability to rotate keys over time, should we choose to do so.

• Secondly, we have implemented pinterface and momijizukamorki's idea to use API keys as 'app passwords' to enable clients to continue to authenticate against Dreamwidth. This means Semagic and other clients can continue to work, but you will need to reconfigure them. See below!

Those are the main changes. Otherwise, tomorrow's code push will deploy the underpinnings of our new authentication storage and bring us into the modern age. At least when it comes to authentication storage. :)

Supporting Semagic (AFTER password changes are deployed)

Ok, so to use Semagic (and other clients), you will need to:

1. Navigate to the Mobile Post Settings page.
2. Click the Generate New API Key button in the Manage API Keys section.
3. Copy the API key that was generated.
4. Change your Semagic password to the API key you copied.
5. That's it, have fun!

If you have any trouble with this, please let us know.

Comments

[silvan_lady]

Bug has gone - thanks! That's what I love about DW.

Regarding the Server Reply issue, if both accounts had been broken I would just have assumed it was 'one of those things' but my other journal works fine.

Here's an example of a server reply I get after clicking the link in the error message dialogue box:-

events_1_allowmask 1 events_1_anum 189 events_1_event Is+%27unprecedented%27+the+most+over-used+word+of+the+year+so+far%3F%0D%0A%0D%0AI+can+think+of+several+alternatives+without+even+trying%21 events_1_eventtime 2020-04-16 23:40:00 events_1_itemid 6668 events_1_logtime 2020-04-16 22:40:56 events_1_security usemask events_1_subject Words... events_1_url https://silvan-lady.dreamwidth.org/1707197.html events_count 1 prop_1_itemid 6668 prop_1_name commentalter prop_1_value 1587380253 prop_2_itemid 6668 prop_2_name current_location prop_2_value on my wayto bed prop_3_itemid 6668 prop_3_name current_mood prop_3_value irritated prop_4_itemid 6668 prop_4_name current_moodid prop_4_value 112 prop_5_itemid 6668 prop_5_name interface prop_5_value flat prop_6_itemid 6668 prop_6_name picture_keyword prop_6_value Writing old prop_7_itemid 6668 prop_7_name picture_mapid prop_7_value 831 prop_8_itemid 6668 prop_8_name taglist prop_8_value english language, covid19 prop_9_itemid 6668 prop_9_name xpostdetail prop_9_value

Interestingly, when I first tried to reply, it was rejected as having text not valid in UTF-8 coding. There were two small squares at the end of the server reply which didn't show up in the code window, but did show once pasted here. I deleted them. (edited to fix typos)

[quirrc]

You see, prop 9 with name "xpostdetail", its value is truncated, that is, when script on server side generates the reply, it gives error when the value of xpostdetail is generated. Report it to support so they will know what to look for.

[silvan_lady]

Thank you, I will do that!