Decoupled TAN: "Got neither 3956 nor HITAN with tanProzess=2"

[witschko]

Hey everybody,

i've been testing the decoupled TAN process with two different banks (Kreissparkasse and VR). It seems the current implementation doesn't work with both of them. Both only send HKTAN::TAN_PROZESS_S and DO NOT send HKTAN::TAN_PROZESS_2 as part of a successful response (examples are attached to this issue).

But the current implementation assumes that only messages that contain the HKTAN::TAN_PROZESS_2 have been confirmed by the user successfully. It seems that is not correct at least for KSK and VR banks.

At the moment we solve the issue in checkDecoupledSubmission() by also setting $isSuccess to true if the HITAN is a HKTAN::TAN_PROZESS_S but still checking if it is an outstanding message and returning false if so.

But I'm not sure if this is the final way to go...any help is very appreciated.
decoupled.log

[Philipp91]

Okay let's see. Starting on PDF page 37 in section "B.4.2.2.1 Einfach-Sicherheitsfreigabe bei Prozessvariante 2", in step 2c, we today only support the "(B)" branch. However, the response that your bank sends isn't the "(A)" branch either:

1. For any 2c response, we need one HITAN with TAN_PROZESS_2 ("Die Nachricht enthält auch ein Segment HITAN mit TANProzess=2 als Beantwortung des HKTAN.").
2. For 2c (A), we additionally need a HITAN with TAN_PROZESS_4.
3. For 2c (B), we additionally need a HITAN with TAN_PROZESS_S.

The response you posted only contains only one HITAN overall, not two. So there's the following possible explanations:

• You cropped the response / made a mistake when formatting it and there are in fact two HITAN, we just didn't see them both.
• It's not in fact a 2c response. Are you sure the authorization is done?
• The bank has a bug -- maybe they skipped over the part of the specification that I quoted in (1.) above. It's subtle at the end of a page and before the A/B list.
• It's a different scheme altogether. For instance in "B.4.2.2.2 Synchrone Eingabe von Mehrfach-Sicherheitsfreigaben in einem Dialog bei Prozessvariante 2", the final step (here it's 4c) requires only one HITAN with TAN_PROZESS_S. Same for B.4.2.2.3. Can you somehow confirm that we're in the simple case B.4.2.2.1 here?
• We might even be in the 2c step of those two, which is the confirmation of the first authorization (that's done with one S), which isn't the end of the overall process. Though you received HIRMS:4:2:3+0020::Der Auftrag wurde ausgeführt.. Can you somehow confirm that the process is actually done at this point (and just phpFinTS doesn't realize)?

[witschko]

Thank you for your quick and detailed response. I also checked B.4.2.2.1 and absolutely agree that there should be another HITAN with TAN_PROZESS_2.

I've attached a log of a full flow for a getStatementOfAccount which needs a TAN since the startdate is more than 3 months in the past.

So to answer you suggestions:

• It seems there is no crop or other mistake of the logs since if the Test-logger works correctly the log should be complete
• I'm sure the authorization is done because I'm getting a positive response with the statements included
• I don't think it is a bug of the bank...I have the same issues for Kreissparkasse (Baden-Württemberg) and Volksbanken/Raiffeisenbanken and both are no small banks
• I assume we are in B.4.2.2.1 but I don't know how to confirm?! I use the Secure Go Plus/S-pushTan App and just have to confirm the request in the app which seems to work

But maybe it seems i have to check with the bank...
decoupled.log

[Philipp91]

Maybe the "bug" is a widely accepted deviation from the specification, perhaps because many people missed that part in the spec or because they didn't bother to implement it that strictly (ignoring an extra segment could be the default behavior depending on how the code base is structured). Short of asking the bank, perhaps you could try the same or a similar sequence of messages/commands with a different FinTS client, and specifically client that also allows you to log the requests and responses. Then we can see whether that client receives the same response (and interprets it differently) or whether it receives a different response (due to having sent a different kind of request, in which case we'd have to look more closely on the request side).

[Masegi]

Is there a way to fix this? Got this too for blz 55090500

[SegFaulty]

Maybe the "bug" is a widely accepted deviation from the specification

run in this BUG month later on Sparkasse ...

and the solution is ... ?

[Philipp91]

We need to figure out what the right way forward is. Since it seems to be a deviation from the specification, we should go with the herd, i.e. try to do what everyone else is doing. And because it's not specified, we need to figure it out experimentally.

perhaps you could try the same or a similar sequence of messages/commands with a different FinTS client, and specifically a client that also allows you to log the requests and responses. Then we can see whether that client receives the same response (and interprets it differently) or whether it receives a different response (due to having sent a different kind of request, in which case we'd have to look more closely on the request side).

[timrasche]

Same on 35650000. Rlly frustrating, Sparkasse has completly turned off pushTAN 1.0 and only 2.0 (decoupled) is possible. Whole Banking function not work any more.

Is there anything i could do to speed up this task?

[timrasche]

Maybe this helps, the TAN segment that was returned on checkDecoupledSubmission is "S" (const TAN_PROZESS_S).

Then, line 488 there was no outstanding part found, setTanRequest is called but no action after that?

The author wrotes "At the moment we solve the issue in checkDecoupledSubmission() by also setting $isSuccess to true if the HITAN is a HKTAN::TAN_PROZESS_S" but this doesnt help, because the origin request (where the tan was requested for) is not executed!

[Philipp91]

decoupled.log

This bank also glosses over another part of the specification: In Schritt 1a, it mandates that the response from the bank contain either 0030 or 3076. In the latter case, we'd be done (2c immediately, which involves HIRMS to deliver the result the user wanted) -- that's clearly not what's happening. In the former case (0030), the bank wants additional authentication, and as per 1b it sends HITAN(4) and 3955. Those two things they implemented, but the 0030 they forgot. I guess that segment is somewhat redundant, given that 3955 indicates that it's 1b just as well.

[Philipp91]

because the origin request (where the tan was requested for) is not executed!

Ah so you have the opposite experience? Because @witschko noticed this error message "as part of a successful response" and explicitly confirmed "I'm sure the authorization is done because I'm getting a positive response with the statements included".

And in your case, you say you get a response that is not success (no HIRMS), but also doesn't contain 3956 (which would indicate that the authentication is still pending)?

Would you be able to post the response message you're receiving and ideally also the corresponding request that you sent? Similar to the decoupled.log files posted above -- be sure to erase sensitive details from it, without changing the length of the message, i.e. replace sensitive characters with _ or so.

[timrasche]

I'm sorry, maybe it was not clear enough.

And in your case, you say you get a response that is not success (no HIRMS), but also doesn't contain 3956 (which would indicate that the authentication is still pending)?

I'm pretty sure the request as @witschko wrote is success. I've forked the repo and modify the code on checkDecoupledSubmission. $isSuccess is not true because HKTAN::TAN_PROZESS_S was found in segment (i only describe the function not the underlaying data (dont know about this)). After that the code in "else" was executed. The check on $response->findRueckmeldungen(Rueckmeldungscode::STARKE_KUNDENAUTHENTIFIZIERUNG_NOCH_AUSSTEHEND) was FALSE! Therefore there is no authentication required and the setTanRequest is set. But as you can see not the processActionResponse (not part of code). On my modification i'm execute processActionResponse anyway and the result is what i need. On the origin code i got the message "there was no tan needed for this action" and its aborting if i serialize the action. With this modification it works for the moment, but i known is little bit "hacky".

I've try to extract these details from log, but needs some time (due missing sandbox and must wait for some customer to execute these steps)

[timrasche]

@Philipp91

there you go - hope it will help.

hbci.log

[Philipp91]

Perfect, thanks!

Side remark: This bank also doesn't send 0030 alongside the 3955. I guess it's good that phpFinTS never insisted on this part of the spec.

It's great that your record also includes a 3956 ("not yet confirmed") response for contrast. In fact, even two of them. And then on the third status query, the confirmation is done and the server delivers the result. And as you say, it's a successful result, HIRMS is present. And as suspected, they send only HITAN(S) but not the HITAN(2) that the specification also demands. So we have to infer from the absence of 3956 alone that the authentication is complete. And complete can mean successful or permanently failed, and we can infer from the presence of the result HIRMS that it was a success in this case.

Please try this patch: Philipp91@3b32a2a

It should be equivalent to what you did, but less hacky.