No scheme like this one will prevent a determined attacker from activating the "debug feature", by the simple expedient of reverse engineering the code to locate the part which, in the software code, will look like:
if (is_good_password(password)) {
activate_debug();
}
and turn it into:
if (true) {
activate_debug();
}
which is usually only a matter of turning a conditional jump into an unconditional jump, or an unconditional non-jump (i.e. a nop opcode). It is not even hard to do, even in big pieces of software (e.g. I did it once for Windows 2000, to allow for testing a custom CSP -- CSP must be signed, and the Microsoft-provided solution for deactivating the signature verification on development platforms was good only up to Win2k SP2, or WinXP, while I had a Win2k SP4; so I had to hack into the advapi32.dll, which took me 3 hours).
That being said, if you just want to verify a password, the easy way is to store in your software a password-verification token, i.e. a hash value computed over the password. No need to bring the whole paraphernalia of digital signatures ! Just a simple hash, and this can accommodate passwords of any length. The software embeds the hash value; when the "debug" URL is entered, it hashes the part after the "debug/" and sees if it matches the recorded hash value. Thus, the password does not appear in the software code itself (neither in cleartext, or merely "scrambled"), and you can use a "password" short enough to be typed.
Digital signatures are any good here only if you have an unbounded number of "Debbies", and you want to be able to give a "debug password" to each Debbie, so that each Debbie has her own password distinct from the passwords given to the other Debbies, and you want to make it impossible for an evil Debbie, regardless of how much reverse engineering she does, to recompute the other passwords from the one she already has (if you have only, say, 20 Debbies, you can just include 20 hash values in your code; by "unbounded" I mean "potentially millions"). This is a pretty specific scenario. An example is "product keys" -- digital signatures could theoretically thwart product-key-generators. Nevertheless, the strongest digital signature will do no better than a password hash against an attacker who does a few hours of reverse engineering on the code to locate the right conditional jump opcode. The signature would not protect against illicit access to the debug code; it protects only against extending an illicit access to an industrial scale, giving it to many other customers without requiring a local modification of the code -- a so-called "hack".
For the hash function, if in doubt, use SHA-256 -- if (and only if) the "password" is long and random enough (say 128 random bits). If the Debbie is allowed to choose a "meaningful" password (one that a human being will be able to remember, as opposed to have it written down on a piece of paper), then you should use a hash function which resists dictionary attacks, e.g. PBKDF2 or bcrypt.
Do not use the "encrypt with the private key" way of describing a signature; it is a terrible explanation, which does not work for all signature algorithms. It is just an historical way with which RSA was first presented, but even for RSA it is wrong: it does not take padding into account, and padding is essential for security (see PKCS#1). Just forget it. There is nothing wrong in "using the private key to sign some data" and "using the public key to verify some data".
