All right, now after the lengthy discussion on user names and ids let’s have some simple rules:
The last point was not mentioned previously but it is quite logical, isn’t it? The system identifies the user by a fixed random user id. But the user identifies itself to the system by a nickname that can be changed once the user is logged in and his id is known.
Security engineer and architect with 30+ years across Alcatel, Sony, Software AG, and Toyota. Started in embedded systems and telecom, moved through R&D, senior management, and back to engineering by choice.
Co-invented Near Field Communication (NFC) and authored 5 international standards for ISO, ECMA, and ETSI. Built enterprise security programs from zero twice, for Sony FeliCa and for Software AG (1500+ engineers, 100+ products). Patent holder in applied security automation, with a second patent pending for hermetic build systems.
I work across the full stack of security: application security, embedded systems, cryptography, supply chain, cloud infrastructure, and vulnerability management. My background in both engineering and management means I operate at the architecture level and at the policy level, whichever the problem requires.
advice attack authentication breach cloud cost costs Cryptography Development disk encryption economics embedded encryption general Google guidance hash hashing inevitability internet management mobile network news NSA Password password database password management passwords philosophy Physical security privacy protection quality rules security social society software software design software security technology user information vulnerability workshop
Biometrics – any good? « Holy Hash!2012-08-04 13:15 /
[...] The first question that should be asked then, “what’s it good for, anyway?” A characteristic that is fairly stable, cannot easily be changed at will, – that’s a fairly reasonable user name, i.e. the user identification. Even then, it is a questionable approach because it is a good idea to let users change names. [...]