Comments for NickTelford.net

Comment on Authenticating a login by Peter Curd

Peter Curd — Mon, 21 Jun 2010 22:09:37 +0000

I agree entirely – the “logging in” system for an application should be exactly as you describe, an “Authentication” phase followed by a background “Authorisation”.

These days, most web based systems could replace login with email – although there is some problem there with emails changing and display names not.. I like the below system:

Old Name – Replaced with
“username” = “email address” (or “e-mail address”, never “e mail address”)
“password” = “pass phrase” (password is also a compound noun)
“login” as in the process = “Authentication”
“user id”/”nickname” = “Display Name”

But it confuses people so we stick with username, password and nickname etc.

In a business world, fitting with other apps is often more important than good grammar. If a customer wants to “login” not “authenticate” then that’s what they get. If a user wants “primary securing identity key” I’m sure they’d get that too.

Comment on Documenting Code Correctly by Roy Patterson

Roy Patterson — Thu, 12 Nov 2009 21:30:46 +0000

I concur.

Comment on Trust, Twitter and Passwords by Nicholas Telford

Nicholas Telford — Wed, 11 Feb 2009 21:55:46 +0000

The FriendFeed system is much more secure than the plain text system, granted. However it does have the draw back that the user has to explicitly discover their “Remote Key”. This is a concept that only really power users will easily grasp and overcomplicates the process.

I prefer the LiveJournal method because you ask the user for the password once (on an SSL domain) then you get a challenge from LiveJournal. You then sign every API call with a hash of the challenge and password. The great thing about this approach is that you can easily store this hash without the worry of the password being retrievable.

Comment on Trust, Twitter and Passwords by Daniel

Daniel — Wed, 11 Feb 2009 21:39:02 +0000

Surely a simpler solution would just be to incorporate an API Key system whereby each user get’s allocated a random string, their key. Both friendfeed and wordpress incorporate this method.

Comment on Lies, deceit and Christians by Lazesharp.net » Blog Archive » How to fool the media

Lazesharp.net » Blog Archive » How to fool the media — Tue, 25 Dec 2007 15:31:38 +0000

[...] website here has opened my eyes to the ineptitude of journalists around the country, not only in researching the facts but also in attaining [...]

Comment on A frontend for configuring FUSE filesystems by dimitri

dimitri — Mon, 09 Jul 2007 08:09:54 +0000

Hi, I was thinking about working on a similar tool -> what is your status on this and is there chance of cooperation? For instance, I could help you with the GTK front-end, or anything else. Please reply by mail

Dimitri

Comment on A frontend for configuring FUSE filesystems by Alex Forrow

Alex Forrow — Tue, 19 Jun 2007 23:06:30 +0000

Sounds pretty dam good. It’ll be good to have a good UI to get no-hassle filesystem access to remote hosts on a per-user basis. NFS is good(-ish) but is not much use if you don’t have root (not to mention its routing complexities, and oh yeah, total lack of security). Few things to add though:

You say it should connect on start-up, but sometimes wouldn’t it be better to connect as the user logs in? If a system had loads of users (on NIS or similar) it would be crazy to mount them all even when they may not be used. Also, on a laptop network connections may not be available until the user has logged in and connected to wireless. Maybe there could be an option for this?

Also, the use of authorized_keys is good, but that would allow any form of ssh use on the remote host with no authentication (which may or may not be acceptable). Would the gnome-keyring be useful here to store passwords?

Lastly, I think there’s a typo where you mean fusetab instead of fstab :p

Good work with that, look forward to seeing something.

Alex