The QR code is not relevant here. QR is just a way to encode some arbitrary date in a way which a computer (or a smartphone) can decode based on a photo of the printed code.
What you suggest is, in fact, basic password authentication. Although you call the password a "PIN", it still is a password: something that fits in the brain of the human user, and the user enters it when needed.
Indeed, let's see the point of view of the attacker who has stolen the phone, and wants to gain access to the webapp. Through some reverse engineering, he obtains the stored K'. Then, for every possible password (PIN), the attacker can compute the corresponding K, just like the phone would do. That "K" is just an encoding of the password. There is no way for the attacker to know which potential K is the right one without talking to the server; the attacker is then in the position of an online dictionary attack. In that sense, this scenario is not really different from a simpler basic authentication in which the webapp just sends the password to the server.
However, if we look at the details, there are two points where your suggestion slightly changes the security model:
Since the password is encoded with the stored value K', the attacker must know that K' to enact his attack. That is, the attacker cannot do it without first stealing the phone (at least if the encoding is done properly -- there are many ways to botch usage of encryption). This may enhance security when compared with a basic "show the password" authentication. One might even claim that the whole system is two-factor authentication in that the attacker must obtain both the PIN ("something you own") and the phone ("something you have") to perform the attack. However, since smartphones are quite complex computers, they suffer from the same issues with malware and keyloggers, and since the PIN code is typed on the phone itself, the two factors are not as isolated from each other as we would wish.
The authentication value (the K) is sent as a "QR code": in the proposed system, K must be, at some point, known to both the mobile app and the server, so there must be some communication. A QR code is a communication channel which goes through the phone camera, suitable for situations where a more common network socket is inapplicable. This K is the important value; knowing K grants access to the server. But you encode it as a QR code, meaning that the K will be printed on a screen or on paper at some point, and be quite visible. This is weak against shoulder surfers. We usually don't like it when secret values are made so visible.
This can be enhanced. Instead of the QR code, use normal network. We could call it device pairing (and that name is a reasonable answer to your specific question, i.e. the terminology for this pattern). Namely:
- User has an account on a Webapp, on which he usually authenticates with a password.
- User launches the mobile app for the first time. The mobile app talks to the server and asks for the user's password.
- With the user's password, the app authenticates with the server, and registers on the server an app instance specific authentication token: some random value is generated (on the app or on the server, it does not really matter) and "stored" in some way on the phone.
- For each subsequent connection, the server will accept the connection from the user only if it "combines" both the phone-stored value (that the server remembers as being associated with that specific user) and the user-specific PIN code.
There are many ways to do this "combination"; some are cryptographically good, others are not. In the case you describe, the combination works that way: what the phone stores is not the authentication token K itself, but a transformed value K' which is an encryption of K with the PIN code; the "combination" is then decryption of K' with the PIN code as key. If the "encryption" is a single invocation of a good block cipher, this may work. As with all things crypto, implementation is a matter of delicacy.
The QR code, here, would just be a way to convey the authentication token from the server to the phone. It seems redundant and useless: this value K is a secret, it won't be shown to just anybody, only to the right, duly authenticated user. So that does not avoid an initial authentication with the normal webapp password. The only scenario I see where it makes sense is when the user logs on the webapp with his computer (the computer has a nice keyboard, making password entry easy), and wants to pair his phone with his account without actually making any network call between the phone and the server. This seems a bit weird, though: to obtain the app, the phone must have been connected to the Internet, and it will have to be connected to actually talk to the server.
