I simply use "@reg.surname.com" for example "yahoo@reg.smith.com". Using the reg. subdomain keeps the domains e-mail address space available for more important things.
I quite fancy using "<first name>@<site name>.surname.com" like "john@yahoo.smith.com" that way I can have all my family using the same method but, unfortunately, my e-mail provider can't support it (yet).
I did this with my Gmail account, I only use it for storage and haven't given it to anyone. It is Issssss@gmail.com where I = my first initial and ssssss = my surname.
I still get 30 spam e-mails a day (for the record Gmail only lets about 2 or 3 into my Inbox). My guess is it's because my ISP email (also: Issssss@myisp.com) has been used in a dictionary.
Spammers obviously know people are going to be signing up to Gmail.
The functionality that the various common IE libraries and API's used in Windows provide would still need replacements if Internet Explorer was made a completely standalone and uninstallable application.
If an Internet Explorer exploit uncovers a fault in part of Windows then I would argue that that is an advantage to the architecture, definately not a disadvantage.
The guys over at Mozilla or Opera don't have an operating system to maintain. Microsoft do.
More code => higher chance of programmer error, thoughtlessness, and bugs.
More shared code => less code to debug and maintain
Yes you have hit all the major faults right on the head. However let's see if i can point out why they aren't so bad
Change of uri/domain -
A fairly uncommon event for most well established websites (obviously not torrent sites:P) and this could be taken into account by keeping both domains/uri's live long enough for users to transfer their account across somehow. Maybe indicating a move and asking the user to accept it, in which case it simply uses the old and new domain string sequentially to accomplish the changeover. Obviously this could be exploited and leads to a new form of phishing - but would be rare - Probably the biggest problem:(
Installation of new software -
* Using extensions or bookmarklet like buttons (that keep javascript out of the scope of other scripts in the webpage) which are now pretty commonplace and native to browsers. * You can even use javascript within the website html itself, although much more risky, it can viewed by the user in the page source and cheating webmasters risk exposure. This is no different from dodgy webmasters not chosing to store passwords as hashes automatically now. * Some kind of signed javascript (.jar file) which can't be tampered with (don't know how feasible that is) which verifies that the script in use is from a source that everyone knows about, is open source, and has been checked for bugs by a large number of people.
Hash weakness -
I have no idea how much weaker a hash with a known constant, for example in MD5, is. Is xxxxxxxCCCCC where CCCCC is a known string as difficult to break as xxxxxxx alone (which would be ideal)? It is an issue given that webmasters could have access to thousands of hashes with the same string constant. But then again now they have your password in plaintext while being processed.
Do the benefits outway the risks of this idea though?
* The webmasters task of stealing plaintext passwords directly is made much much more difficult. * Having to crack hashes with a constant string in them might not provide much advantage over hashes without..i would guess it depends on the hashing algorithm - i'm obviously no expert. * Websites without HTTPS still benefit because passwords aren't sent across the wire (talking authentication here not content privacy remember) in the clear.
I love that Schneier quote, anything devised is always going to be exploitable somewhere by somebody much smarter than yourself. I have no delusions that it will be perfect but I think it moves some of the risks about and might be interesting to try out.
Berkeley researchers propose a Mozilla extension to stop phishing. They claim that users only need to remember one password and one image for their lifetime to securely log in to any number of sites.
I just thought I would share how I would implement a very simple unified password system on the web without any risk of your password being stolen, either by dodgy webmasters or by man in the middle attack. I have no idea if it is original but seems near flawless to me and I'm going to implement it on my site shortly.
Registration process --------------------
* Your client side script or extension takes your master password and appends 'thewebsiteyouresigningupto.tld' or 'generic.webhostorisp.tld/website/path/' to the end, perhaps with a nice seperator * MD5 (or some other) hash this string using javascript or client side code. This becomes the website 'registration hash'. * The server stores this directly into it's user database without any further manipulation.
Login process -------------
* Server generates a random string (the current time since the linux epoc would do) and sends it in a hidden form field. Call this the session string. * The client takes master password appends the website dependant domain or uri etc and reproduces the registration hash for that specific website. * Take the registration hash and append the session string sent by the server and hash it again. This becomes the 'login hash' that is used only once, for this login only. * The server retreives the registration hash from it's database, appends the same session string that it sent to, and kept associated with, the visitor and hashes it to produce the same 'login hash'. * The server compares this expected login hash to the login hash from the user and authenticates the user if they match.
Pros ----
* No information that can result in successful authentication for different session is sent across the wire. * The user gets to hash their password client side so doesn't have to worry about whether the server side to storing it securely. * The webmaster has no control over the client side hashing and can't modify anything their end to get your password to another website. * The password for the website is unique to the websites domain/URI but the master password entered by the user can be used on any number of websites, this makes it easy to remember and conveinient.
Cons ----
* The registration transaction is open to a man in the middle attack - but at worst someone will only be able to comprimise that specific website because the registration hash is made unique to each website. * The server side needs to be able to keep track of what session string it sent to the client - can be done by means of ip address, user-agent and cookie association etc. The server side also needs to ensure noone can authenticate for the current session by similar means. * The worst one - if a website changes URL's then all the user passwords become invalid. But what the hell - send them all new ones by e-mail.
If somebody was willing to produce a standard and implement this process across the web, with browser plugins etc we'd never have to remember lots of passwords again or have them stored anywhere but in our heads.
"Ah well, this will be modded down as troll or flamebait by the rabid stars wars geeks that infest Slashdot."
Highlighting one of idiosyncrasies of Slashdot is that in acknowledging you will probably be modded down and flaming the Slashdot crowd you have prevented yourself from being just that (so far anyway) and actually increased your chances of being modded up.
I just thought I'd pick you up on that rather than comment on Star Wars. But Yes I agree with you. I thought the first trilogy was bad enough.
If all websites started MD5'ing passwords before they were transmitted to the server then this would become completely ineffective for the attack mentioned in grandparent.
As two other folks have already replied this is due to free-fall.
The acceleration due to gravity onboard the International Space Station is about 8.80 m/s^2 as opposed to 9.80 m/s^2 here on the surface. This is because the ISS is in low Earth orbit.
Geostationary orbits experience approx. ~0.22m/s^2 (that one is from memory)
> tabs will be very "'basic' due to fears from Microsoft that tabbed browsing might scare off too many users.
Does Microsoft think users are stupid and can't learn new things? OK some users are total newbies, but damn i'm sure they are intelligent enough to find/Google a way to turn tabs off.
Or better yet leave them off by default? Nobody is preaching that tabs have to be on by default, just that there is a demand for them. You know...that'd actually be 'original'. Lookup 'originality'. Or better yet 'innovative' or 'thought'. Innovative is before original in the dictionary by the way so you better look that up first..just incase you can't work out you can flick backwards.
I guess someone will comment and say i'm being totally ignorant but Microsoft shouldn't be insulting their potential users with such feable excuses.
"the KDE developers should follow Apple's lead and focus more on the needs of users, instead of insisting on software perfection."
Opera.. [Yes damnit I'm mentioning Opera to be made an example of in an Apple-KHTML-Firefox related article so mod me offtopic if you must] manages a smooth, sexy well refined, suite with distinct lack of clumsiness, a fast and obviously efficient backend, with excellent standards compliance and features. You can almost taste the oodles of care put in to perfecting the product for the 'users needs'.
IMHO 'software perfection' in terms of a smooth and stress free user experience (and I don't mean just the UI - Opera particuarly has never, for me personally, crashed or blown bugs at me with 12 months of use) is waaaaaay more important than 100% compliance to standards or sitting on the cutting edge of the blade.
Firefox almost makes up for it's clumsy floppering about (which i'd rather not digress into and start a flame) with it's feature set. But, for me, and MLHO, not quite.
The "needs of the users" in the way meant in the entry, for example a better renderer, don't come into the equation much in terms of 'perfection' here. You can enter one discussion and everyone says ~"Use firefox, it's more secure!", then someone pipes up that logically, and quite rightly, it is not (again let's not digress into that debate). Then everyone says ~"But firefox has tabbed browsing and standards compliance and all these neat extensions!". The fact is the geekdom minority pushed, and is still pushing, the majority to use something most people simply don't care much about. IMHO the 'average Joe' primarily wants a program that won't crash, slow down, or exhibit visible or annoying bugs.
Most of my friends I admitedly pushed into using Firefox still use the default theme and 0 extensions, some even use windows (note the little w:P) but they still like to bitch like hell when it flumps after opening X tabs (although none have defaulted back to IE)
Obviously you need a balance of the latest whizzy gizmo compatibility and careful implementation, but being a bit of a perfectionist myself I would urge the KDE team to stick their nose up and get on with what it is they are doing. I wouldn't let a minority of people push them about. There is nothing wrong with being a perfectionist, even if you are seemingly 'wasting' time or a bit behind the 'competition'. Good for you KDE.
XPI installation isn't the most dangerous part of the IFRAME exploit. As posted in this comment by some Anonymous Coward it can steal your cookies and probably more some.
Slashdot Mirror
Another option of course is @..com ...yahoo@john.smith.com and then use john@smith.com on a whitelist ...neat.
I simply use "@reg.surname.com" for example "yahoo@reg.smith.com". Using the reg. subdomain keeps the domains e-mail address space available for more important things.
I quite fancy using "<first name>@<site name>.surname.com" like "john@yahoo.smith.com" that way I can have all my family using the same method but, unfortunately, my e-mail provider can't support it (yet).
The subdomain will specify the label or folder.
I did this with my Gmail account, I only use it for storage and haven't given it to anyone. It is Issssss@gmail.com where I = my first initial and ssssss = my surname.
I still get 30 spam e-mails a day (for the record Gmail only lets about 2 or 3 into my Inbox). My guess is it's because my ISP email (also: Issssss@myisp.com) has been used in a dictionary.
Spammers obviously know people are going to be signing up to Gmail.
That risk is no different to hashed passwords being stored by most website databases now.
Yes you have hit all the major faults right on the head. However let's see if i can point out why they aren't so bad
:P) and this could be taken into account by keeping both domains/uri's live long enough for users to transfer their account across somehow. Maybe indicating a move and asking the user to accept it, in which case it simply uses the old and new domain string sequentially to accomplish the changeover. Obviously this could be exploited and leads to a new form of phishing - but would be rare - Probably the biggest problem :(
Change of uri/domain -
A fairly uncommon event for most well established websites (obviously not torrent sites
Installation of new software -
* Using extensions or bookmarklet like buttons (that keep javascript out of the scope of other scripts in the webpage) which are now pretty commonplace and native to browsers.
* You can even use javascript within the website html itself, although much more risky, it can viewed by the user in the page source and cheating webmasters risk exposure. This is no different from dodgy webmasters not chosing to store passwords as hashes automatically now.
* Some kind of signed javascript (.jar file) which can't be tampered with (don't know how feasible that is) which verifies that the script in use is from a source that everyone knows about, is open source, and has been checked for bugs by a large number of people.
Hash weakness -
I have no idea how much weaker a hash with a known constant, for example in MD5, is. Is xxxxxxxCCCCC where CCCCC is a known string as difficult to break as xxxxxxx alone (which would be ideal)? It is an issue given that webmasters could have access to thousands of hashes with the same string constant. But then again now they have your password in plaintext while being processed.
Do the benefits outway the risks of this idea though?
* The webmasters task of stealing plaintext passwords directly is made much much more difficult.
* Having to crack hashes with a constant string in them might not provide much advantage over hashes without..i would guess it depends on the hashing algorithm - i'm obviously no expert.
* Websites without HTTPS still benefit because passwords aren't sent across the wire (talking authentication here not content privacy remember) in the clear.
I love that Schneier quote, anything devised is always going to be exploitable somewhere by somebody much smarter than yourself. I have no delusions that it will be perfect but I think it moves some of the risks about and might be interesting to try out.
I just thought I would share how I would implement a very simple unified password system on the web without any risk of your password being stolen, either by dodgy webmasters or by man in the middle attack. I have no idea if it is original but seems near flawless to me and I'm going to implement it on my site shortly.
Registration process
--------------------
* Your client side script or extension takes your master password and appends 'thewebsiteyouresigningupto.tld' or 'generic.webhostorisp.tld/website/path/' to the end, perhaps with a nice seperator
* MD5 (or some other) hash this string using javascript or client side code. This becomes the website 'registration hash'.
* The server stores this directly into it's user database without any further manipulation.
Login process
-------------
* Server generates a random string (the current time since the linux epoc would do) and sends it in a hidden form field. Call this the session string.
* The client takes master password appends the website dependant domain or uri etc and reproduces the registration hash for that specific website.
* Take the registration hash and append the session string sent by the server and hash it again. This becomes the 'login hash' that is used only once, for this login only.
* The server retreives the registration hash from it's database, appends the same session string that it sent to, and kept associated with, the visitor and hashes it to produce the same 'login hash'.
* The server compares this expected login hash to the login hash from the user and authenticates the user if they match.
Pros
----
* No information that can result in successful authentication for different session is sent across the wire.
* The user gets to hash their password client side so doesn't have to worry about whether the server side to storing it securely.
* The webmaster has no control over the client side hashing and can't modify anything their end to get your password to another website.
* The password for the website is unique to the websites domain/URI but the master password entered by the user can be used on any number of websites, this makes it easy to remember and conveinient.
Cons
----
* The registration transaction is open to a man in the middle attack - but at worst someone will only be able to comprimise that specific website because the registration hash is made unique to each website.
* The server side needs to be able to keep track of what session string it sent to the client - can be done by means of ip address, user-agent and cookie association etc. The server side also needs to ensure noone can authenticate for the current session by similar means.
* The worst one - if a website changes URL's then all the user passwords become invalid. But what the hell - send them all new ones by e-mail.
If somebody was willing to produce a standard and implement this process across the web, with browser plugins etc we'd never have to remember lots of passwords again or have them stored anywhere but in our heads.
Highlighting one of idiosyncrasies of Slashdot is that in acknowledging you will probably be modded down and flaming the Slashdot crowd you have prevented yourself from being just that (so far anyway) and actually increased your chances of being modded up.
I just thought I'd pick you up on that rather than comment on Star Wars. But Yes I agree with you. I thought the first trilogy was bad enough.
What would you rather see a seqeul or a prequel?
(No 'neither' replies please)
If all websites started MD5'ing passwords before they were transmitted to the server then this would become completely ineffective for the attack mentioned in grandparent.
Think about it.
A service like this has been in the UK for well over a year. It's 2580 and costs about the same I think.
URL: http://www.shazam.com/uk/do/home
As two other folks have already replied this is due to free-fall.
The acceleration due to gravity onboard the International Space Station is about 8.80 m/s^2 as opposed to 9.80 m/s^2 here on the surface. This is because the ISS is in low Earth orbit.
Geostationary orbits experience approx. ~0.22m/s^2 (that one is from memory)
Afraid not. Pumping this URL into some robots.txt validators shows it to be invalid. Apparently "Accept:" isn't part of the robots.txt standard.
Which only leaves META tags..for XML feeds...I guess it's about time robot exclusion standards were revised.
At 16 I believe you still need parental consent on marriage. At 18 you can marry even if they oppose the marriage.
I could be wrong
Social Engineering => Stupidity Exploitation => Slashdot Entertainment
http://www.starwarssequeltrilogy.com/
Make of it what you will, the episode 2 and 3 synopsis were somewhat accurate.
XUL? Yuck!
I'm wondering why the Google homepage doesn't detect suitable browsers and serve up have a nice search switcher that doesn't reload like Yahoo.com
Better yet just combine all the subsites into a results page (in a really nice innovative way).
Why have tabs at all..going back to a search box and search button only without handicap would be impressive from Google.
Cheers! very helpful option I missed.
> tabs will be very "'basic' due to fears from Microsoft that tabbed browsing might scare off too many users.
Does Microsoft think users are stupid and can't learn new things? OK some users are total newbies, but damn i'm sure they are intelligent enough to find/Google a way to turn tabs off.
Or better yet leave them off by default? Nobody is preaching that tabs have to be on by default, just that there is a demand for them. You know...that'd actually be 'original'. Lookup 'originality'. Or better yet 'innovative' or 'thought'. Innovative is before original in the dictionary by the way so you better look that up first..just incase you can't work out you can flick backwards.
I guess someone will comment and say i'm being totally ignorant but Microsoft shouldn't be insulting their potential users with such feable excuses.
I think the only software I've ever seen made with pascal was Cubic Player
The brilliant (and free) Xnews client is written in Delphi (Pascal).
Pascal still lives on as Delphi and is still widely used, albeit mostly for win32 development.
"the KDE developers should follow Apple's lead and focus more on the needs of users, instead of insisting on software perfection."
:P) but they still like to bitch like hell when it flumps after opening X tabs (although none have defaulted back to IE)
Opera.. [Yes damnit I'm mentioning Opera to be made an example of in an Apple-KHTML-Firefox related article so mod me offtopic if you must] manages a smooth, sexy well refined, suite with distinct lack of clumsiness, a fast and obviously efficient backend, with excellent standards compliance and features. You can almost taste the oodles of care put in to perfecting the product for the 'users needs'.
IMHO 'software perfection' in terms of a smooth and stress free user experience (and I don't mean just the UI - Opera particuarly has never, for me personally, crashed or blown bugs at me with 12 months of use) is waaaaaay more important than 100% compliance to standards or sitting on the cutting edge of the blade.
Firefox almost makes up for it's clumsy floppering about (which i'd rather not digress into and start a flame) with it's feature set. But, for me, and MLHO, not quite.
The "needs of the users" in the way meant in the entry, for example a better renderer, don't come into the equation much in terms of 'perfection' here.
You can enter one discussion and everyone says ~"Use firefox, it's more secure!", then someone pipes up that logically, and quite rightly, it is not (again let's not digress into that debate). Then everyone says ~"But firefox has tabbed browsing and standards compliance and all these neat extensions!". The fact is the geekdom minority pushed, and is still pushing, the majority to use something most people simply don't care much about. IMHO the 'average Joe' primarily wants a program that won't crash, slow down, or exhibit visible or annoying bugs.
Most of my friends I admitedly pushed into using Firefox still use the default theme and 0 extensions, some even use windows (note the little w
Obviously you need a balance of the latest whizzy gizmo compatibility and careful implementation, but being a bit of a perfectionist myself I would urge the KDE team to stick their nose up and get on with what it is they are doing. I wouldn't let a minority of people push them about. There is nothing wrong with being a perfectionist, even if you are seemingly 'wasting' time or a bit behind the 'competition'. Good for you KDE.
Shame! Feeel ashamed! all of you! shaaaame, I hope these actresses never read of your cold heartless disprespectful opinions...
:-P
besides it's quite obviously Major Kira Nerys. Fools.
Yeah because compiling Mozilla/Firefox is reeeaal quick and package archives update like a whippet with an arse full of dynamite.
I guess geeks just don't have alot of time to spare.
If Slashdot wasn't so eager to sniff Firefox's hind leg this post would, and should, have mentioned Mozilla 1.7.8 as being released too.
XPI installation isn't the most dangerous part of the IFRAME exploit. As posted in this comment by some Anonymous Coward it can steal your cookies and probably more some.