I have a system which is a CRM of sorts, it essentially manages customers claims that they have been mis-sold insurance.
This system is expected to handle a fairly high volume of claims and several call center desks have been enlisted to that effect.
The general workflow of the system is; call center recieves a claim and enters it onto the system submitting it for approval, head office check the details of the claim approving it if it meets the neccasary criteria. On approval a one time only secure URL is emailed to the customer which they can then visit to view the 5 generated documents which contain the details of their claim. Each document requires at least one signature (from the claimant and their partner if appropriate), our client has specified that only one of these documents requires a proper signature (legally) which must be received by snail mail from the customer. The other documents they would like digitally signed (to speed up the claim process, simplify it for the claimant, cut down on paper, postage costs, etcetera).
In doing this i have to take into account that the majority of claimants likely have very little technical knowledge and so must keep this process as simple (user friendly) as possible.
As mentioned each claimant is sent a 'one time only' URL which they can use to login to sign the document, when they have viewed the documents they are given the option to sign; at which point they are asked for a password, this is then hashed (along with some personal data) and added to the footer of each document page. A visual signature is generated with nice signature like font and added to the relevant signature boxes along with the disclaimer "Please accept the electronic signature above as acceptance of your terms of business and instructions to proceed".
They can then download the generated PDF for their own records.
The system commissioner seems to think this is acceptable, howver I am not sure and would like to know if this is the right way to go about it, and if not, is there a better way bearing in mind i must keep this as simple as possible.
Thanks.
This is an incorrect use of a message digest function. The resulting hash of a secret be given to a user (or attacker...), even if it is salted. Hashes are useful for password storage because it adds an extra complexity that the attacker must overcome. Adding personal data can make the hash more difficult to break, but if an attacker had a lot of computing resources they could make a lot of guesses and then obtain someones personal information as well. A good way to think of it as that a resulting hash will leak information about the original message if the attacker can make enough guesses.
There are 2 ways you can go about doing this. The first method is something i just made up that I like. So the user logs in with this 1 time URL and then is presented with a draw box, where by using their mouse courser they sign their name. This image is then appended with a secret that only you know (Cryptographic Nonce) to create the Key "k" in an MAC, the Message "m" would be the entire document that is to be signed. This is a good way to tie together these important pieces of information using cryptography. This could also be used to prove that the signed document wasn't tampered with. However, the resulting hash which is being used as authentication code could only be verified and created if you have the secret that you provide. This would come into play if you need to prove the authenticity in a court room.
A more common approach is to use PDF's Built-In digital signatures. I have used this first hand in contract agreements. If you do go this route and a case where to make it to court it would likely be easier to defend your self in saying that a user signed the document. There are however some serious problems with this approach. Most important this is very difficult for non-tech savvy users, although it maybe okay to automatilly singing them with Adobe's PDF SDK. A draw box could still be used, and the image of the clients name could be written to the document prior to the application of the digital signature. Key distribution is going to be a pain in the ass. Its costs money because you have to pay for to use a PKI provided by someone like VeriSign (* insert vomit here *). Further more a PKI is defending against attacks that are not reliant to your needs. Although going this route means that anyone should be able to verify the authenticity of this document.
You just want to prove that a document is signed and wast tampered with. Given the nature of this problem I would make sure a lawyer looks over your proposed solution.
Hey there, I know this answer is a "bit" late, but hopefully it'll help others who read it as well. I also work in the insurance field and understand the importance of security when signing documents. I am aware of a few services available for digital signatures, here I linked to the one we're working with at our NYC office. It's great cause it really solves many issues and we don't need to print documents out any more or be worried about security. In any case, I hope this helps. :)
I would generate an image(barcode or barcode-matrix), like a checksum that is generated with some nasty algorithm on the server (RSA sounds good to me) that could be checked later if needed. Don't use a signature font, that's just tacky.
Related
I would like to know how to protect a contract/email from being altered. The scenario is this:
Me and person X are signing a contract. So first I sign the contract, scan it in and email it to person X. Person X then print, sign, scan and email me the contract back.
My question is, how can prevent person X from altering the contract after I have signed. Is there someway to prevent this? Or a way to prove the altered contract with both our signatures on is not the same as the one I signed.
Keeping the copy I signed is not good enough because person X would simply argue I was the one who altered it. Keeping the email I sent would also not work since altering emails is trivial.
Unfortunately, there's no way to prevent this scenario in the way we currently use technology.
In many countries, there's technology infrastructure in place to securely sign digital documents, but the "print/sign/scan" cycle people have become used to prevents any kind of meaningful technological protection measures against this scenario.
If the people you're doing the contract with insists in using analog technology or the country you live in does not have the technological or legal infrastructure to make this work digitally, you'll have to revert, as Artjom B mentioned, to a trusted third party - a witness or a notary.
From a more legal viewpoint (IANAL and TINLA)
Keeping the copy I signed is not good enough because person X would
simply argue I was the one who altered it. Keeping the email I sent
would also not work since altering emails is trivial
In this last paragraph, the tone of your question indicates that you're more worried about providing technological proof of your claims than the fact that your claims are true. If a contract is ever contested (which may or may not be unlikely), it's not up to you to provide technological proof. It's up to the court to decide using preponderance of evidence.
Yes, from some programmer's viewpoint, altering a local email is technologically trivial - but for most people that's arcane black arts (or impossible).
If it reassures you, the original email is very probably retained in the service provider independently of your local modifications, and will be available on legal request.
Finally, forgery is a serious offense - my guess is that most people won't engage in it without a very strong motivation. Consider carefully if this is the case.
Here's a (simplified) example of my situation.
The user plays a game and gets a high-score of 200 points. I award high-scores with money, i.e. 1€/10 points. The user will print a "receipt" which says he won €20, then he gives it to me, I make sure the receipt is authentic and has never been used before and I hand him his prize.
My "issue" is in the bold part, obviously. I should be able to validate the "receipt" by hand, but solutions with other offline methods are welcome too (i.e. small .jar applications for my phone). Also, it must be hard to make fake receipts.
Here's what I thought so far, their pros and their cons.
Hashing using common algorithms i.e. SHA512
Pros: can easily be validated by mobile devices, has a strong resistance to faking it with higher values (if a context-depending salt is used, i.e. the username).
Cons: can be used multiple times, cannot be validated by hand.
Self-made hash algorithms
Pros: can be validated by hand.
Cons: might be broken easily, can be used multiple times.
Certificate codes: I have a list of codes in two databases, one on the server and one on my phone. Every time a receipt is printed, one of these is printed in it and set as "used" into the database. On my phone, I do the same: I check if the code is in the database and hasn't been used yet, then set as "used" in the database.
Pros: doesn't allow for multiple uses of the same code.
Cons: it's extremely easy to fake a receipt, cannot be validated by hand.
This sounds like a classic use case for an Hash-based message authentication code (HMAC) algorithm. Since your idea of "by hand" is "using a smartphone", not "with pecil, paper, and mind", you can compute the hash and print it on the receipt, and then validate it on the phone or the back-end server.
The "missing point" is to use more systems at once so that, together, they work in the needed way. In this case, we can use HMAC for authenticating the message and a list of "certificate codes" to make sure one doesn't use the same receipt over and over.
Another idea might also be to hash the time when the receipt is outputted to the client and print it on the receipt. When someone shows you the code on the receipt, you make sure that hash hasn't been used yet and that it's valid (i.e. the message produces that hash), then you add it to the list of "used hashes".
Thanks to #RossPatterson for suggesting HMAC.
As most of you know, email is very insecure. Even with a SSL-secured connection between the client and the server that sends an email, the message itself will be in plaintext while it hops around nodes across the Internet, leaving it vulnerable to eavesdropping.
Another consideration is the sender might not want the message to be readable - even by the intended recipient - after some time or after it's been read once. There are a number of reasons for this; for example, the message might contain sensitive information that can be requested through a subpoena.
A solution (the most common one, I believe) is to send the message to a trusted third party, and a link to the that message to the recipient, who then reads this message from the 3rd party. Or the sender can send an encrypted message (using symmetric encryption) to the recipient and send the key to the 3rd party.
Either way, there is a fundamental problem with this approach: if this 3rd party is compromised, all your efforts will be rendered useless. For a real example of an incident like this, refer to debacles involving Crypto AG colluding with the NSA
Another solution I've seen was Vanish, which encrypts the message, splits the key into pieces and "stores" the pieces in a DHT (namely the Vuze DHT). These values can be easily and somewhat reliably accessed by simply looking the hashes up (the hashes are sent with the message). After 8 hours, these values are lost, and even the intended recipient won't be able to read the message. With millions of nodes, there is no single point of failure. But this was also broken by mounting a Sybil attack on the DHT (refer to the Vanish webpage for more information).
So does anyone have ideas on how to accomplish this?
EDIT: I guess I didn't make myself clear. The main concern is not the recipient intentionally keeping the message (I know this one is impossible to control), but the message being available somewhere.
For example, in the Enron debacle, the courts subpoenaed them for all the email on their servers. Had the messages been encrypted and the keys lost forever, it would do them no good to have encrypted messages and no keys.
(Disclaimer: I didn't read details on Vanish or the Sybil attack, which may be similar the what comes below)
First of all: Email messages are generally quite small, esp. compared to a 50 mb youtube vid you can download 10 times a day or more. On this I base the assumption that storage and bandwidth are not a real concern here.
Encryption, in the common sense of the word, introduces parts into your system that are hard to understand, and therefore hard to verify. (think of the typical openssl magic everybody just performs, but 99% of people really understand; if some step X on a HOWTO would say "now go to site X and upload *.cer *.pem and *.csr" to verify steps 1 to X-1, I guess 1 in 10 people will just do it)
Combining the two observations, my suggestion for a safe(*) and understandable system:
Say you have a message M of 10 kb. Take N times 10 kb from /dev/(u)random, possibly from hardware based random sources, call it K(0) to K(N-1). Use a simple xor operation to calculate
K(N) = M^K(0)^K(1)^...^K(N-1)
now, by definition
M = K(0)^K(1)^...^K(N)
i.e. to understand the message you need all K's. Store the K's with N different (more or less trusted) parties, using whatever protocol you fancy, under random 256 bit names.
To send a message, send the N links to the K's.
To destroy a message, make sure at least one K is deleted.
(*) as regards to safety, the system will be as safe as the safest party hosting a K.
Don't take a fixed N, don't have a fixed number of K's on a single node per message (i.e. put 0-10 K's of one message on the same node) to make a brute force attack hard, even for those who have access to all nodes storing keys.
NB: this of course would require some additional software, as would any solution, but the complexity of the plugins/tools required is minimal.
The self-destructing part is really hard, because the user can take a screenshot and store the screenshot unencrypted on his disk, etc. So I think you have no chance to enforce that (there will always be a way, even if you link to an external page). But you can however simply ask the recipient to delete it afterwards.
The encryption is on the other hand is not a problem at all. I wouldn't rely on TLS because even when the sender and the client are using it, there might other mail relies who don't and they might store the message as plain text. So, the best way would be to simple encrypt it explicitly.
For example I am using GnuPG for (nearly) all mails I write, which is based on some asymmetric encryption methods. Here I know that only those I have given explicitly permission can read the mail, and since there are plug-ins available for nearly all popular MUAs, I'ts also quite easy for the recipient to read the mail. (So, nobody has to encrypt the mail manually and might forgot to delete the unencrypted message from the disk...). And it's also possible to revoke the keys, if someone has stolen your private key for example (which is normally encrypted anyway).
In my opinion, GnuPG (or alternatively S/MIME) should be used all the time, because that would also help to make spamming more difficult. But thats probably just one of my silly dreams ;)
There are so many different ways of going about it which all have good and bad points, you just need to choose the right one for your scenario. I think the best way of going about it is the same as your 'most common' solution. The trusted third party should really be you - you create a website of your own, with your own authentication being used. Then you don't have to give your hypothetical keys to anyone.
You could use a two way certification method by creating your own client software which can read the emails, with the user having their own certificate. Better be safe than sorry!
If the recipient knows that the message might become unreadable later and they find the message valuable their intention will be to preserve it, so they will try to subvert the protection.
Once someone has seen the message unencrypted - which means in any perceivable form - either as text or as screen image - they can store it somehow and do whatever they want. All the measures with keys and so one only make dealing with the message inconvenient, but don't prevent extracting the text.
One of the ways could be to use self-destructing hardware as in Mission Impossible - the hardware would display the message and then destroy it, but as you can see it is inconvenient as well - the recipient would need to understand the message from viewing it only once which is not always possible.
So given the fact that the recipient might be interested in subverting the protection and the protection can be subverted the whole idea will likely not work as intended but surely will make dealing with messages less convenient.
If HTML format is used, you can have the message reference assets that you can remove at a later date. If the message is open at a later date, the user should see broken links..
If your environment allows for it, you could use the trusted boot environment to ensure that a trusted boot loader has been used to boot a trusted kernel, which could verify that a trusted email client is being used to receive the email before sending it. See remote attestation.
It would be the responsibility of the email client to responsibly delete the email in a timely fashion -- perhaps relying on in-memory store only and requesting memory that cannot be swapped to disk.
Of course, bugs can happen in programs, but this mechanism could ensure there is no intentional pathway towards storing the email.
The problem, as you describe it, does sound very close to the problem addressed by Vanish, and discussed at length in their paper. As you note, their first implementation was found to have a weakness, but it appears to be an implementation weakness rather than a fundamental one, and is therefore probably fixable.
Vanish is also sufficiently well-known that it's an obvious target for attack, which means that weaknesses in it have a good chance of being found, publicised, and fixed.
Your best option, therefore, is probably to wait for Vanish version 2. With security software, rolling your own is almost never a good idea, and getting something from an established academic security group is a lot safer.
IMO, the most practical solution for the situation is using Pidgin IM client with Off-the-Record (no-logging) and pidgin-encrypt (end-to-end assymetric-encryption) together. The message will be destroyed as soon as the chat window is closed, and in emergency, you can just unplug the computer to close the chat window.
My boss is against requiring our users to have secure passwords, even going so far to request they be setup by default to have passwords the same as their username. What should I do in this situation? What would you do?
Update - Some users have brought up the question of whether the application needs high security. This isn't credit card information for example but does include sensitive information and a mailing list management and sending functionality.
Make the best case you can for strong passwords and then, unfortunately, if they do not see your point of view either do what they asked or find a better job.
What you're told.
...
Then respecfully let the superior know in writing what problems that will cause.
Do not CC anyone. This is my opinion, of course. If you CC it will look obvious. You really just want security but you have to cover yourself. You don't have to be a horse's behind about it though.
Keep it in your sent box, print it, whatever, if you are truly concerned.
edit - You do what you're told unless it is some sort of question of moral turpitude. Then you simply document what you did and why you did it. Just remember that if you do not document it - it did not happen. Documenting is something you should always be doing.
As a compromise there are way better defaults, like using the user's serial number, year of birth, initials, some combination, depending what you have on hand. Not the most secure but not the least either.
Does your application require high security? If the data controlled by your software is not sensitive and the risk to the user is low, perhaps you really don't need strong passwords.
If your app does pose a significant risk to the user if passwords are allowed to be weak, you should make that case as best you can, in writing. If you can quantify risk and liability, do so, but ultimately you will have to leave the decision up to your superiors.
There's nothing wrong with a default password the same as the username provided that the system requests that the user creates a new password the first time the user logs in. You then allow anything as a password if there is low security requirement. If you're handling sensitive data then password strength needs to be of an appropriate level. You haven't said what data you're hiding. There's no point in having super strong passwords (12 chars, lower case, upper case, digit and symbol and no words from dictionary) if it's an intranet based time tracking system. If you're accessing something like a tax record database then you'd need at least two level authentication - string password and one time key generation.
You should hit him hard. Explain him/her what sort of bad publicity might happen because of this, also depends on the data, data protection act and similar stuff can actually cause serious liability. Basically doing it such can be considered as a software defect therefore company can be responsible for the results.
Basically you need to give him a reason which will bite him, scare him. That's how you sell security and insurance :)
If you boss can't figure out such a simple thing and can't trust guys like you at the end, maybe you should start looking for a new place which you can actually use your own potential instead of dealing with these sort of issues.
This is poor security.
If it can result in, for example, identify theft for your users, then you have a very serious social responsibility to improve the security. You are essentially dealing with people's lives. Go to your boss, go to his or her boss. Print out these comments and bring them along. Go to your legal department and tell them how much exposure this causes. If your company was dumping toxic waste whistle blower laws would apply. Personal information and identify theft is no less serious. Do everything in writing to cover yourself and to provide a paper trail of evidence for the lawsuits that will surely follow. Don't allow your company to deny any knowledge of the risk after the fact. Companies that knowingly implement horrible security that results in identify theft should fail in the market place and deserve nothing but shame, ridicule and failure.
If on the other hand this poor security can result in comparatively minor things then your your effort to improve the security can also be scaled back from what I describe above.
Email him your concern (in a non-aggressive way). Give the logical attack vector, reveal what will be exposed. Close by asking for his confirmation taht this is his instruction. Then send to him (only him, as previously suggested)
Email archive both your original email and his confirmation. This will cover you if something happens.
Argue the case for having stronger passwords but also make a compromise. Have the passwords as defaulting to the username with certain letters replaced with numbers perhaps? This all depends on the system as well. If this is an internal system, it could be quite hard for somebody to gain access to the system & do any harm.
Do what your boss says, but make the passwords expire within a relatively short time period.
I would put together a summary document on password policies, benefits of strong passwords, etc and submit it to him for review and try and make it part of company policy. If they still don't like it then do what they ask, as they are the end client and you have done your part to educate them of the pitfalls.
why using user/pasword in the first?
to log user activity?
the operating system asks for it?
if you want to connect an action (whatever) with an user, I as an user would require that my password be safe!
if your boss is afraid, that he may loose "knowledge", if a user is away, and he needs to get access to that uesers data, require everyone to write down his password in a sealed envelope.
if your boss does not trust you, kündige!
Peter
I would consider what is behind the request to have it that way first.
Is it really an active user with username+password what should be being set up in the first place? i.e. perhaps the user should be receiving an email with a link to activate :)
When does the sensitive information comes into the system? Assuming it is input by the user, just have an activation step where the user changes the password (or is the first time (s)he has a password for that matter).
Notice that if you are working with sensitive information, it is likely there is a law relating to it. I would also look into that, if it is illegal it makes for a strong case, and in that case you should Really consider saying plain no (explaining the reason first of course).
Did he say they had to be all lowercase...
Did he explicitly say they had to not include numbers...
You should hack into his account. Then he will know why username=password dont work.
I've run into this before, where they didn't want to use a secure password &/or lock down their computers.
Then it happened our website had been hacked into (not b/c of a password breach, but b/c of flawed component/module for the CMS that we used - but that's a different story) and in a few different occasions, people have logged into the exec's computer to view a few inappropriate things.
The reason for this explanation is to say that it wasn't until this and a few other case studies that I brought to their attention that they understood just how important it is for secure passwords.
As a solution, you may try to do some research on case studies where a breach has occurred on systems or sites where the information stored or protected wasn't terribly important, but the damaged cause and money it took to recover was substantial - such as someone setting up a phishing scam on your site, the holding hostage a server or site & having to wipe clean the whole box to start over, or some other type of breach.
Anyways, take it for what it's worth.
A few things come to mind that you might want to share with your boss -
The biggest security threat isn't outsiders, it's the folks you work with. If there has been someone fired with cause since you've been there, bring that up with your boss - "What if XXXX had access to other people's accounts?" That person many not steal data, but they may try to vandalize the system or mess with data out of spite. Or could they even share that data with a competitor?
Propose a somewhat stronger default as a compromise - username and 4 digits of home phone number. It's not much stronger but it does make guessing a little harder.
People can make fairly secure passwords by using mnemonics. However, you need to train people in how to do that. Offer to hold a session with your users on how to create secure passwords. Honestly, it's not just good for where they work but for anyone who shops or banks online. Something that's easy for IT people who have to juggle multiple passwords may be harder for others.
BTW, I found a nice javascript generator of mnemonic passwords.
http://digitarald.de/playground/mnemonic-password-generator/
I've found situations where a password is shared by several people, because sometimes security is less important than other stuff. Specially in intranets.
A solution can be to store the IP address of each user. It's a security measure closer to security cameras than to locks, but it might be enough for what your boss has in mind.
Slough may be onto something - but it might be too harsh.
Maybe take a combination approach.
Do what`s asked - but when presenting it, make sure it breaks, or you have some mechanism that will show how or why it is not a secure approach. (This will go through a review process before being implemented right?)
Also find any documentation that describes "best coding practices" from respected industry peers either in books or online or even office colleagues that may be able to back up your point of view. Present your sources, and if their ignored, you've done your duty and due diligence, and the final outcome will rest on the superiors shoulders.
I am a programmer at a financial institute. I have recently been told to enforce that all new user id's to have at least one alpha and one numeric. I immediately thought that this was a horrible idea and I would rather not implement it, as I believe this is an anti-feature and of poor user experience. The problem is that I don't have a good case for not implementing this requirement.
Do you think this is a good requirement?
Do you have any good reasons not to do it?
Do you know of any research that I could reference.
Edit: This is not in regards to the password. We already have similar requirements for that, which I am not opposed to.
One argument against this is that many usernames / ids in other areas do not require numeric components. It's more likely that users will be better able to remember user ids that they have used elsewhere -- and that is more likely if they do not need to include numerics.
Furthermore, depending on the system, the user ids may work well as defaults when connecting to external systems (ssh behaves this way under unix-like systems). In this case, it is clearly beneficial to have one ID that is shared between systems.
Using the same ID in multiple places improves consistency, which is a well-known aspect of good software interfaces. It's not too difficult to show that the way people interact with a system is a user-interface, and should adhere to (at least some) of the well-known interface guidelines. (Obviously ideas like keyboard shortcuts are meaningless if you're considering the interactions between multiple, possibly unknown, systems, but aspects such as consistency do apply.)
Edit: I'm assuming that this discussion is about usernames or publicly visible IDs, NOT something that pertains directly to security, such as passwords.
I would begin by asking them for their specific reasons behind this. Once you have a list of bullet points and the reasons why, it's easier to refute or provide alternatives.
As for general ideas:
This is opinion, but adding a numeral to a username won't necessarily increase security. People write down usernames on post it notes, most users will just add a '1' to the beginning or end of their username, making it easy to guess.
From a usability standpoint, this is bad as it breaks the norm. Forcing them to add a numeral to their username will just lead to the above point. They will simply add a '1' to the end or beginning of their username.
Remember, the more complex an authentication system is, the more likely a general user is to find ways to circumvent it and make their link in the chain weak.
UserIDs? Requiring passwords to be alphanumeric is generally a good idea, since it makes them more resistant to a dictionary attack. It doesn't really make any sense for usernames. The whole point of having a name/password combo is that the name part doesn't have to be kept secret.
If you're working at a financial institution, there are probably regulations about this sort of thing, so it's most likely out of your hands. But one thing you can do is make it clear to the user when he has entered an invalid ID. And don't wait until he clicks submit; show some kind of message right next to the field, and update it as he types.
A few of the answers above have a counter-argument: If the users pick the same username they use on the other sites, then they are also likely to pick the same or similar passwords for the financial site, lowering security.
A reason not to do it: If you impose more restrictions than they are used to on the users, they will start writing down the login information, and that's an obvious loss of security.
Both of the bank accounts I have require an alphanumeric username and two passwords for the online login. One of them also has a image I have to remember. The two passwords have to change once a month or so. Therefore, I have all the login information right here on a text file. (Even looking at it doesn't make any sense; I'll have to go down to the bank and reset my passwords again. That's a grand total of 7 password resets for 6 logins. Talk about security, not even I can access my account.)
it's good if it's in their password (as alas, financial companies like to deny you this security right [i'm talking to you american express]).
username, i say no, unless they want to.
A username will (presumably) need to be quoted on the phone when calling for support so it will be publicised unlike a password. Also, the username field won't be masked out in browsers like password fields are, so it will have much more exposure and get cached/logged in various places, so the 'benefit' of the added security will be undone in no time.
And the more difficult you make things, the more likely a user is to write it down somewhere which again undermines security (same applies for password policies actually, but that's another story!)
I also work at a financial institution and our usernames (both real people and production IDs) are all lowercase, alphabetical, up to 8 characters and I've never considered it a problem... avoids the confusion of 0 vs O, 1 vs I, and 8 vs B - unless you work for the same company as me and are about to implement a new policy...
Adding any feature adds costs. It will take time now to build and test it, and in the future to support it. No feature should be built without a really good reason.
This feature is pointless. Usernames are not supposed to be kept secret, so having strong usernames has no advantage. It is probably worth spending time making passwords (or other authentication factors) strong, but users should be able to communicate their username to other users without that being a security risk.
If your application imposes extra constraints on the choice of user ID then some of your users will have a different user ID for your application than for the other applications in your environment. Note: I'm assuming that this is an internal application (for use by employees) rather than in Internet-facing application.
Having inconsistent usernames adds a number of specific risks:
It will make the audit trail harder to follow (a serious security risk).
It may add cost if you later start using single sign on.
It will cause a bad user experience as users have to remember that this application uses a weird username.