8 ms·

Putting aside the issues we all know exist with this, I wonder what their rationale was...

j_baker 16y ago
Probably some variant of "Whoops. We named the username column 'password' and the password column 'username'. Guess we need to fix this!"
- jedsmith 16y ago
  That sounds like it would be a fun system to inherit.
  - BoppreH 16y ago
    Maybe if you use the Dwarf Fortress term. "Losing is fun!"
- lukifer 16y ago
  I've seen far too many codebases that use the order of the returned fields rather than the field names. Scary.
  - state_machine 16y ago
    But it's faster that way, and you don't have to store the name in every row like with those No-Seequill whatnots. </sarcasm>
    - uxp 16y ago
      Your closing sarcasm tag isn't warranted, in a large number of circles.
  - Dilpil 16y ago
    Aye, me as well. And later written my fair share of them when the going got rough.
  - patio11 16y ago
    Have I mentioned recently that Japanese megacorps' engineering excellence does not extend to web apps? student.setName(resultSet.nextString())); //column 75
    - didip 16y ago
      Please, do share the story in detail. Perhaps a blog post?
stretchwithme 16y ago
their rationale was ir
Stormbringer 16y ago
Security is hard. If you're asking for an account name and password form someone, you're effectively committing to playing security hardball. Also, you're asking the users to trust you, and perhaps the level of trust that you're askign for is more than you really need. Stackoverflow is an interesting case where they thought about issues of identity and authentication, and decided to go with OpenId. Their rationale would be something along the lines of "we want to map comments to an identity, but we don't need/care about authentication, we can let someone else do that". Unfortunately, OpenId kind of sucks, but that's a different story. An interesting example is HackerNews where they keep a cookie around so I don't need to log in everytime. This is enormously much less secure (anyone else on the same machine can impersonate me just by going to the HN website). But the security implications of someone impersonating me are low (shoot, given my contrarian nature and history of Iconiclasm and Heresy someone else trying to 'destroy' my online rep would probably actually improve it instead :D ) Now Facebook does the same thing, but in Facebook's case this is enormously bad, evil and wrong (tm) since the data they control access to is much more sensitive and private. Speaking of different stories, here's another one to illustrate when you want to be able to uniquely identify someone, but going with a full on username/password system is overkill and more hassle than it is worth. Was talking to some guys who want to take registrations/expressions of interest for an upcoming Science Fiction convention. The convention is a couple of years out, so presumably some proportion of the people will need to change their address details between now and then. But if they do a name/password thing, people will forget the passwords (and choose badly even if they do remember it), it imposes a security and trust burden upon them to maintain the database securely. Basically, they need to identify the people to a reasonable degree of security, but names/passwords is overkill. So I decided that what they needed was a shared secret instead. If the person gives their email address when they sign up (and sign ups range from OMG take my money now to "eh, send me a reminder when we get to three months out"), then when that person wants to change their name/address details, they just send them an email with a link. The link contains the shared secret built in (e.g. a token). The shared secret will eventually expire, but for a while they can get in and edit their own details. If someone doesn't want to give their email when they sign up, no problem, they just can't offer them those convenience features.
- thestoicattack 16y ago

Probably some variant of "Whoops. We named the username column 'password' and the password column 'username'. Guess we need to fix this!"

jedsmith 16y ago
That sounds like it would be a fun system to inherit.
- BoppreH 16y ago
  Maybe if you use the Dwarf Fortress term. "Losing is fun!"
lukifer 16y ago
I've seen far too many codebases that use the order of the returned fields rather than the field names. Scary.
- state_machine 16y ago
  But it's faster that way, and you don't have to store the name in every row like with those No-Seequill whatnots. </sarcasm>
  - uxp 16y ago
    Your closing sarcasm tag isn't warranted, in a large number of circles.
- Dilpil 16y ago
  Aye, me as well. And later written my fair share of them when the going got rough.
- patio11 16y ago
  Have I mentioned recently that Japanese megacorps' engineering excellence does not extend to web apps? student.setName(resultSet.nextString())); //column 75
  - didip 16y ago
    Please, do share the story in detail. Perhaps a blog post?

stretchwithme 16y ago

their rationale was ir

Stormbringer 16y ago

Security is hard. If you're asking for an account name and password form someone, you're effectively committing to playing security hardball. Also, you're asking the users to trust you, and perhaps the level of trust that you're askign for is more than you really need. Stackoverflow is an interesting case where they thought about issues of identity and authentication, and decided to go with OpenId. Their rationale would be something along the lines of "we want to map comments to an identity, but we don't need/care about authentication, we can let someone else do that". Unfortunately, OpenId kind of sucks, but that's a different story. An interesting example is HackerNews where they keep a cookie around so I don't need to log in everytime. This is enormously much less secure (anyone else on the same machine can impersonate me just by going to the HN website). But the security implications of someone impersonating me are low (shoot, given my contrarian nature and history of Iconiclasm and Heresy someone else trying to 'destroy' my online rep would probably actually improve it instead :D ) Now Facebook does the same thing, but in Facebook's case this is enormously bad, evil and wrong (tm) since the data they control access to is much more sensitive and private. Speaking of different stories, here's another one to illustrate when you want to be able to uniquely identify someone, but going with a full on username/password system is overkill and more hassle than it is worth. Was talking to some guys who want to take registrations/expressions of interest for an upcoming Science Fiction convention. The convention is a couple of years out, so presumably some proportion of the people will need to change their address details between now and then. But if they do a name/password thing, people will forget the passwords (and choose badly even if they do remember it), it imposes a security and trust burden upon them to maintain the database securely. Basically, they need to identify the people to a reasonable degree of security, but names/passwords is overkill. So I decided that what they needed was a shared secret instead. If the person gives their email address when they sign up (and sign ups range from OMG take my money now to "eh, send me a reminder when we get to three months out"), then when that person wants to change their name/address details, they just send them an email with a link. The link contains the shared secret built in (e.g. a token). The shared secret will eventually expire, but for a while they can get in and edit their own details. If someone doesn't want to give their email when they sign up, no problem, they just can't offer them those convenience features.

thestoicattack 16y ago