What kind of creatures are subject to Phantom Rogue’s Tokens of the Departed?

This might get a little fiddly, but I was curious how people would rule on this aspect of Phantom Rogue’s level 13 feature, "Tokens of the Departed"

When a life ends in your presence, you’re able to snatch a token from the departing soul, a sliver of its life essence that takes physical form: as a reaction when a creature you can see dies within 30 feet of you, you can open your free hand and cause a Tiny trinket to appear there, a soul trinket. The DM determines the trinket’s form or has you roll on the Trinkets table in the Player’s Handbook to generate it.

Do you think that the creature necessarily needs a soul to be able to use this feature? IE, would this work on undead or constructs? Flavor text uses "soul" but RAW mechanic just says "when a creature dies" and "has soul" and "does not have soul" aren’t properties of a stat-block.

Thanks for your time.

How can I let players create and move their own tokens in roll20?

When I run D&D online, I want to delegate players to have control of their tokens.

If one of my players tells me they cast flaming sphere, I want to be able to tell them to go find an image of a flaming sphere and put it on the map as a token.

If one of my players turns into a dire wolf, I want to be able to tell them to replace their token with a dire wolf token with the of their choice.

If one of my players uses summon nature’s ally and summons a bunch of critters, I want to be able to tell them to put the critters on the map.

I believe that using the roll20 console I could do this work for the players, but I want to spend my time doing other things, for example running the next player’s turn while this player generates a moonbeam token.

When I’ve tried to use roll20, I always had to create tokens for my players and then delegate them permission to use the tokens, and I frequently got it wrong and had to redo it.

Is there a way to configure roll20 to let my players create and manipulate tokens of their own?

Is `iss` property in JWT tokens redundant?

I’m reading up on some OpenID Connect documentation trying to get my head around the protocol. I came across the issuer property that is common in the JWT tokens. How come this is required if we should always check the signature of the token against the expected endpoint?

I understand that one can validate against either a symmetric or asymmetric hash, but validation is expected either way.

Have I missed an important feature of the JWT?

Are web worker / service worker secure environments to store a password, credit card information, access tokens?

If there is a case where I wish to store sensitive data like a password, credit card information, or access tokens:

Are web workers / service workers a secure environment, where such data can not be compromised? If so, what to do to really secure it? If not so, why not exactly?

Do id tokens need to be signed assymetrically?

Access tokens that are passed to the public in an OAuth flow clearly need to be signed using asymmetric encryption (e.g. RSA) so that they cannot be altered by the client to gain access to new scopes, etc.

Id tokens on the other hand are not used to access any resources on the server. So if the client is able to alter the id token they will not be able to gain access to any extra resources. Does that mean that it would be okay to use a symmetric (HMAC) signature with a secret that is shared between the server and a specific client application (like the oauth client_secret for a given oauth client)?

Why make it difficult to disable MFA tokens?

Some websites make it easy to enrol multiple TOTP apps at the same time but make it difficult to disable these apps. For instance, the user would have to completely reset the MFA settings instead of just disabling one TOTP app, or the user would have to provide a state-issued ID to have this done by user support.

What type of threat scenario does this address? After all, an attacker who would be able to authenticate as a legitimate user would then be able to change the password and lock the legitimate user out, so what is the difference?

Anonimity of Bluetooth tokens

In the context of contact tracing, I have a privacy question.

I have read a few (and “few” is already a bad thing) articles about Bluetooth contact tracing, especially in the context of the Sars-Cov2 pandemic. There are huge privacy concerns in contact tracing.

One solution proposed by reasearchers is to use “changing” device identifiers in order to prevent authorities from tracing an individual’s location history by the usage of beacons in public places or analysis of traces from other devices. The topic is particularly hot in the European Union.

Only question here: regardless of the randomization of the device ID transmitted via Bluetooth, is it already possible to listen for Bluetooth MAC addresses to identify a single device?

Example scenario: in a world where smartphone owners are encouraged to use a legitimate government-powered app (supposed that the government is democratic), a rogue vendor with a large market rate may push a malicious Bleutooth app into their consumer’s phones (a large user base who just clicks on “accept” anything). The malicious app continuosuly scans for Bluetooth MAC identifiers to report home. The addresses are potentially georeferenced. Deanonimyzation might occur.

So far, I have always learned to keep my Bluetooth invisible while I don’t need it and possibly turned off to save battery.

A country or continent-wide contact tracing scheme might be a good excuse to keep Bluetooth on and available for scan.

Question is: what am I getting wrong?

Preventing automated attacks on Tokens without relying on Firewall or Network Infrastructure

Our concern is more on application side prevention automated attacks. Although the firewall does it part to help prevent this, it has been mandated in our development team’s security practices that we need a 2nd level of protection. Solutions such as MFA and CAPTCHA are solutions to a different issue. They help reduce the chances an attacker has to possibly bypass authentication and guess the credentials. What we want here is just basically to detect an automated attack and stop it (or realistically, delay it).

The attack the penetration tester did was this:


This is a link sent to email addresses for password reset. They tried automated enumeration of the token to be able to guess a correct one. Although they were not successful guessing a valid one, they still filed this as a vulnerability since our application failed to catch this automated attack and was not able to block the requests. So, we now have been in a dead end finding solutions for this.

Some solutions we have come up with:

  1. IP Address blocking – seems problematic since requests go through a number of servers and components (firewall –> web server –> app server etc.), it would be extremely difficult to get the source ip address of the requester. Sometimes attacks still could be behind proxies.

This would be doable if the enumeration was something like username and password. We can come up with a logic that detects enumeration of usernames with the same password and start blocking next requests using the same password. In this case, only a token in the input.

Running out of reasons to solve this issue. Can anyone help us on this?