The fact that the authors were obligated to redact file names within the .password-store subdirectory is a wonderful illustration of its “let’s just leak all the metadata” design. I continue to be baffled that so many people have chosen to use it.
It’s annoying that Azure Storage has an ad-hoc capability system and there isn’t a universal one. It’s doubly annoying that they’ve made them hard to use safely. If you’re using the default kind of SAS tokens (capabilities) then you really need to ensure that you have no more than two capabilities issued because they are just a text representation of the permissions and expiry date signed with one of two keys. You can revoke the keys but that’s the only granularity that you get.
The safer way is to use the stored access policy. This adds an indirection layer and says that the holder of the capability has a set of permissions held in a table on the server. To use these properly as capabilities, you need to create one policy per capability and invalidate it to revoke the capability. Doing this is incredibly clunky.
The Azure policy seems to be that you should use Azure Active Directory for all access control, but it’s very expensive for small users, incredibly slow to update, and conflates identification with authorisation in unfortunate ways.
The fact that the authors were obligated to redact file names within the
.password-storesubdirectory is a wonderful illustration of its “let’s just leak all the metadata” design. I continue to be baffled that so many people have chosen to use it.It’s annoying that Azure Storage has an ad-hoc capability system and there isn’t a universal one. It’s doubly annoying that they’ve made them hard to use safely. If you’re using the default kind of SAS tokens (capabilities) then you really need to ensure that you have no more than two capabilities issued because they are just a text representation of the permissions and expiry date signed with one of two keys. You can revoke the keys but that’s the only granularity that you get.
The safer way is to use the stored access policy. This adds an indirection layer and says that the holder of the capability has a set of permissions held in a table on the server. To use these properly as capabilities, you need to create one policy per capability and invalidate it to revoke the capability. Doing this is incredibly clunky.
The Azure policy seems to be that you should use Azure Active Directory for all access control, but it’s very expensive for small users, incredibly slow to update, and conflates identification with authorisation in unfortunate ways.
Sure, but the AI could have exposed twice as much data at one tenth the cost!