Repository navigation
Fix HNSHK security profile version for two-step PIN/TAN - #214
Open
markusrauschergmxnet wants to merge 1 commit into
Open
markusrauschergmxnet wants to merge 1 commit into
markusrauschergmxnet wants to merge 1 commit into
Conversation
The HNSHK signature header always used SecurityProfile(PIN, 1) (one-step)
even when two-step TAN authentication was active. This caused an
inconsistency: HNVSK (encryption) correctly used PIN:2 for two-step,
but HNSHK (signature) still said PIN:1.
Banks that strictly validate the security profile version (notably
HypoVereinsbank/UniCredit) rejected the HKTAN segment with error 9210
("Auftrag abgelehnt") because the signature header claimed one-step
authentication while a two-step TAN segment was present in the message.
This also fixes _bootstrap_mode never being reset after
fetch_tan_mechanisms(), which caused 9075 SCA errors to be silently
swallowed instead of properly raised.
Fixes raphaelm#213
Owner
|
I'll try to find time to test this against my HVB account soonish |
mt-software-de
suggested changes
Oct 18, 2026
Comment on lines
+1308
to
+1310
| # Bootstrap phase (anonymous dialog with sf=999) is complete. | ||
| # Reset so that errors in subsequent authenticated dialogs are properly raised. | ||
| self._bootstrap_mode = False |
There was a problem hiding this comment.
Thanks for this, the bootstrap part solves a problem we ran into as well. It doesn't cover clients restored with from_data, which usually don't call fetch_tan_mechanisms() again and so stay in bootstrap mode, swallowing a 9075. I opened #228, which ends the bootstrap mode in __enter__ instead and covers both cases.
For what it's worth, we can also confirm the security profile change with Consorsbank: PIN:1 in HNSHK is rejected with 9010 Ungültiger Signaturaufbau, PIN:2 works.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
SecurityProfile(PIN, 1)(one-step) even when two-step TAN authentication (e.g.sf=904) was active. The HNVSK encryption header correctly usedPIN:2, but HNSHK still saidPIN:1.9210("Auftrag abgelehnt. Kein eingereichter Auftrag gefunden") because the signature claimed one-step while a two-step HKTAN segment was present._bootstrap_modewas never reset afterfetch_tan_mechanisms(), causing9075SCA errors to be silently swallowed instead of properly raised.Changes
fints/security.py:PinTanAuthenticationMechanismnow uses asecurity_method_versionattribute (default1) for the HNSHK security profile.PinTanTwoStepAuthenticationMechanismoverrides it to2, matching the HNVSK behavior.fints/client.py:_bootstrap_modeis reset toFalseafterfetch_tan_mechanisms()completes, so that subsequent dialog errors (especially9075) are properly raised.Test plan
HITANwith challenge instead of9210Fixes #213