A cup packed with a tin would make a great life hack without increasing space or much cost.
Wednesday, April 30, 2014
Tuesday, April 29, 2014
Leaving the tree in the road
A tree bypass is not only needed in a desert but can also payback its the courtesy in the cities. The tree helps separate the two way road.
Monday, April 28, 2014
Technology is not anti-social, people are
Next time you hear some one say technology is making us anti-social, show them this picture.
Sunday, April 27, 2014
USB Desk vacuum cleaner
Would miss to get this device... powers the vacuum cleaning for your desk or workspace via USB.
Saturday, April 26, 2014
Friday, April 25, 2014
Failed Juggaar
That moment when your juggaar gets you in deeper trouble than it already was. Throwing the shoe after the ball is not a good idea.
The man who survived two nukes
Shared via zidbits.com.
Mr. Yamaguchi’s luck is a double-edged sword, however. What put him in contention for the world’s luckiest man could also be seen as something incredibly unlucky as well. But what made this nondescript man so lucky?
It was August 6th, 1945. Mr. Yamaguchi was on a business trip in Hiroshima, Japan. He was just about to head to the train station with 2 coworkers and return to his home in Nagasaki, when he realized he had forgotten a personal item back in the city.
He was walking back to retrieve the item when the American bomber Enola Gay dropped a nuclear bomb near the center of the city, only 2 miles away from where he was.
The blast blew out his eardrums, temporarily blinded him, and left him with major burns on one side of his body. Yamaguchi recalled seeing a bomber and two parachutes, before there was “a great flash in the sky, and I was blown over“. After finding that his two coworkers also survived, they returned to his home in Nagasaki and had their wounds treated and bandaged.
Despite being seriously wounded, he still showed up for work in the morning. Mr. Yamaguchi was recounting the blast in Hiroshima to his supervisor, when an American bomber dropped the Fat Man atomic bomb onto Nagasaki. His workplace again put him roughly 2 miles from ground zero, but this time he suffered no injuries from the bomb. Unfortunately, he was unable to seek treatment for his now ruined bandages, and suffered from a high fever for over a week.
After the war, Yamaguchi worked as a translator for the occupying American forces before he later returned to work for Mitsubishi. Later in life, Yamaguchi became a vocal proponent of nuclear disarmament. In an interview, Mr Yamaguchi said, “The reason that I hate the atomic bomb is because of what it does to the dignity of human beings.” During a telephone interview he said, “I can’t understand why the world cannot understand the agony of the nuclear bombs. How can they keep developing these weapons?” He also wrote a book about his experiences in the late 1980′s.
In March 2009, Japan officially recognized Yamaguchi as a survivor of both blasts. He is now the only person officially recognized as surviving two nuclear bomb explosions.
Mr. Yamaguchi lived to ripe old age of 93 and died on January 4th, 2010 at his home in Nagasaki.
Mr. Yamaguchi’s luck is a double-edged sword, however. What put him in contention for the world’s luckiest man could also be seen as something incredibly unlucky as well. But what made this nondescript man so lucky?
A Flash In The Sky
It was August 6th, 1945. Mr. Yamaguchi was on a business trip in Hiroshima, Japan. He was just about to head to the train station with 2 coworkers and return to his home in Nagasaki, when he realized he had forgotten a personal item back in the city.
He was walking back to retrieve the item when the American bomber Enola Gay dropped a nuclear bomb near the center of the city, only 2 miles away from where he was.The blast blew out his eardrums, temporarily blinded him, and left him with major burns on one side of his body. Yamaguchi recalled seeing a bomber and two parachutes, before there was “a great flash in the sky, and I was blown over“. After finding that his two coworkers also survived, they returned to his home in Nagasaki and had their wounds treated and bandaged.
A Repeat Performance
Despite being seriously wounded, he still showed up for work in the morning. Mr. Yamaguchi was recounting the blast in Hiroshima to his supervisor, when an American bomber dropped the Fat Man atomic bomb onto Nagasaki. His workplace again put him roughly 2 miles from ground zero, but this time he suffered no injuries from the bomb. Unfortunately, he was unable to seek treatment for his now ruined bandages, and suffered from a high fever for over a week.
After the war, Yamaguchi worked as a translator for the occupying American forces before he later returned to work for Mitsubishi. Later in life, Yamaguchi became a vocal proponent of nuclear disarmament. In an interview, Mr Yamaguchi said, “The reason that I hate the atomic bomb is because of what it does to the dignity of human beings.” During a telephone interview he said, “I can’t understand why the world cannot understand the agony of the nuclear bombs. How can they keep developing these weapons?” He also wrote a book about his experiences in the late 1980′s.
In March 2009, Japan officially recognized Yamaguchi as a survivor of both blasts. He is now the only person officially recognized as surviving two nuclear bomb explosions.
Mr. Yamaguchi lived to ripe old age of 93 and died on January 4th, 2010 at his home in Nagasaki.
Thursday, April 24, 2014
Wednesday, April 23, 2014
Tuesday, April 22, 2014
Tire shoes
Shoes made of tires / tubes: a higher level recycling venture than other reuses of rubber. Shoes from the tire material would infact be a metal-rubber composite and would be even better at performing the job.
Monday, April 21, 2014
Tripped man sculpture
Sculpture making takes to street art showing an 'apparently' out of balance tripped man's sculpture.
Bike wifi rig
A Pakistani out-of-the-box rig of PTCL's evo wingle WiFi device with a motor bike to get internet on the go on cell phone(s) or laptop(s) woulds surely make to our featured posts.
Saturday, April 19, 2014
Friday, April 18, 2014
Thursday, April 17, 2014
Two practically difficult but awesome weapon system combos
#satire.
The Tank gunship...
...the tank battleship,
...and the tank jet-fighter.
...and the tank jet-fighter.
Aluminum directly cast on wood
Directly casting molten metal on wood might cause it to burn, but if done correctly and the fire put out, it can be quite artistic and can make a mechanically sturdy table. Seeing art in metallurgy restores my faith in art ;)
Tuesday, April 15, 2014
Cooling down on ice
Only in Pakistan: Man lays on ice in hot summers to take the heat off. I hope he's not going to put that ice in soda after it...
Monday, April 14, 2014
Sunday, April 13, 2014
Nautilus Dropbox Bug
If you are a linux user and use dropbox to sync your data to the cloud, the latest linux versions some times result in this bug giving errors with dropbox. After the update (or some times just after some changes made by the system in the background), dropbox stops loading and asks to reinstall the propitiatory daemon again (and doing that still doesn't make the application work). This has been covered else where on the internet as "nautilus-dropbox" bug even being an advanced linux user, I didn't find those TL;DR and complicated fixes very friendly and certainly wouldn't recommend to new linux users as it would drive them away - Ubuntu is supposed to be user friendly and most other linux distributions aim for the same. This is one example where jargon and a lot of text on fixing it is present.
You can find some more if you use the search query: "dropbox stopped working on linux needs proprietary daemon".
If you want to fix it after just reading small paragraph of text with 2-3 command lines that you need to enter this is the right place for you. The solution is to simple delete the dropbox binaries and reinstall them (without removing your dropbox settings and index files). This does the trick according to the given link:
For me it didn't work, so I removed the binaries from my home folder and that fixed my application:
Drop me a comment if it didn't work for you.
You can find some more if you use the search query: "dropbox stopped working on linux needs proprietary daemon".
If you want to fix it after just reading small paragraph of text with 2-3 command lines that you need to enter this is the right place for you. The solution is to simple delete the dropbox binaries and reinstall them (without removing your dropbox settings and index files). This does the trick according to the given link:
sudo rm -rf /var/lib/dropbox/.dropbox-dist
dropbox start -iFor me it didn't work, so I removed the binaries from my home folder and that fixed my application:
sudo rm -rf ~/.dropbox-dist
dropbox start -iDrop me a comment if it didn't work for you.
Protecting Your GNU/Linux System from Dropbox
This post has been shared from grepular.com. The actual post can be viewed on the given link.
Typical blog posts about Dropbox security concentrate on data or network encryption. I want to talk about protecting your system from Dropbox the application, as well as Dropbox the company. In this blog post I tell you how to prepare for a theoretical scenario where Dropbox turns malicious. I've done a number of things to make Dropbox run in a much more secure fashion on my Ubuntu laptop. Hopefully I will introduce you to some vulnerabilities that you weren't aware of, and teach how to protect against them. Many of the attacks and defenses described here are portable to apps other than Dropbox.
X11 and File Permissions
First of all, X11 is hideously insecure. I log into my X11 desktop as user "mike". This means that any other process running under the same user id is able to connect to the X11 service, sniff every key I press in any app, and even inject new fake key presses. This is not something new, but a lot of people aren't aware of it. So when you enter your password into your bank's login form in Firefox, or when you type your master password to unlock your super secure password manager vault, it's worth noting that any other process running under the same uid as yours, is able to quietly read what you're typing.
Just to prove it to you, open Terminal and type "xinput list". Find the item with "keyboard" in the name and note down the id. Then type "xinput test TheID" (replacing "TheID" with the id you noted). Now start typing into some other application like your browser address bar. You'll see that in the terminal it is noting down the character code for every key you press.
So I thought to myself, why should I allow Dropbox to potentially attack my X11 session in this way? And more than that, why should I allow it to have access to read and write any file belonging to user "mike"? The first thing I did was create a new password-less user on the system named "mike.dropbox". Under the Terminal program on the Ubuntu desktop run the following:
The next step was to set up Dropbox under that new user. First of all, I needed to give the user "mike.dropbox" temporary access to X11 so I could access the installation GUI as that user. To do this I ran:
You might be thinking now that a "/home/mike.dropbox/Dropbox/" folder which is completely inaccessible to user "mike" is not a lot of use. You might have thoughts about adding the "mike" user to the "mike.dropbox" group, and fiddling with permissions. That is not going to work out well; the dropbox executable will want to create new files owned by "mike.dropbox" only. So what I did next was an "apt-get install samba smbfs". The idea was to export the folder as a network mount, mounting it at "/home/mike/Dropbox/". You can probably use NFS for this too. In my /etc/samba/smb.conf I added:
So now we have a /home/mike/Dropbox/ folder, full of files which appear to be owned by the "mike" user, syncing with the Dropbox cloud, just as before. The only "negative" difference is that we don't get the GUI magic which allows us to see the status of file transfers and such. But now the dropbox process is isolated under the "mike.dropbox" user, it can no longer connect to my X11 session to sniff my key presses, and it can no longer read/write any of the files owned by my main user.
More File Permissions
Ok, so the Dropbox process can no longer read/write any files owned by user "mike". It can still read any globally readable files on the system though and data from volumes like /proc/. Why though? There are only a very limited number of files that it needs to be able to read and write in order to operate. To restrict the process to only being able to read and write certain files, I created an AppArmor profile. Amongst other things, AppArmor allows you to limit an application so it can only read and write certain whitelisted files. Non Debian based systems probably want to use SELinux for this instead. There are plenty of AppArmor tutorials out there, so I wont go into details on how to use it. Basically, you use the command "aa-genprof" on /usr/bin/dropbox to collect a list of which files it accesses and how it accesses them, and you store that list in a special format in /etc/apparmor.d/. Any attempted violations are blocked and logged to /var/log/kern.log.
Quotas
My Dropbox allowance is 8.5GB. So why would I allow the Dropbox application the opportunity to use up more than 8.5GB of disk space on my laptop? It could potentially DOS the system, either maliciously or accidently. So I've implemented filesystem quotas. I'm using ext4, and I have a single / partition so YMMV. First of all I added the options "usrquota,grpquota" to the "/" mount point in /etc/fstab and remounted it with a "mount / -o remount". Then I enabled disk quotas by running the following two commands:
Network Permissions
Another good thing about isolating applications to run under unique uids, is that iptables allows you to specify outgoing firewall rules on a per user basis. If for example, I wanted to block Dropbox from connecting to the Internet all together (I obviously don't), I could simply run the following command as root:
Even though I decided against this sort of blocking, I still wanted to do something interesting to the Dropbox traffic. I have Tor running on my laptop. If I could use Tor to connect to the Dropbox cloud, that would afford me some privacy. This should be safe, as the Dropbox traffic is all secured using encryption, so it isn't possible for a Tor Exit node to MITM it. Doing this would prevent Dropbox from maintaining a log of my whereabouts (IP addresses and times) at least. I editted my /etc/tor/torrc, added the following two lines, and then restarted Tor:
File Encryption
Despite what Dropbox says, they can read the files which you store in your Dropbox folder. The only way to prevent them being able to do that, is by handling the encryption on the client side. Luckily, on Linux this is easy. Do an "apt-get install encfs" and then run the following:
If you want the whole of your Dropbox to be encrypted, rather than just a single folder, you could maybe change your /etc/fstab to mount your Dropbox at "~/.Dropbox.unencrypted" instead of "~/Dropbox/" and place your encfs mount at "~/Dropbox/" instead. The problem with this is, you wont be able to access encrypted files from other devices that don't support encfs.
Typical blog posts about Dropbox security concentrate on data or network encryption. I want to talk about protecting your system from Dropbox the application, as well as Dropbox the company. In this blog post I tell you how to prepare for a theoretical scenario where Dropbox turns malicious. I've done a number of things to make Dropbox run in a much more secure fashion on my Ubuntu laptop. Hopefully I will introduce you to some vulnerabilities that you weren't aware of, and teach how to protect against them. Many of the attacks and defenses described here are portable to apps other than Dropbox.
X11 and File Permissions
First of all, X11 is hideously insecure. I log into my X11 desktop as user "mike". This means that any other process running under the same user id is able to connect to the X11 service, sniff every key I press in any app, and even inject new fake key presses. This is not something new, but a lot of people aren't aware of it. So when you enter your password into your bank's login form in Firefox, or when you type your master password to unlock your super secure password manager vault, it's worth noting that any other process running under the same uid as yours, is able to quietly read what you're typing.
Just to prove it to you, open Terminal and type "xinput list". Find the item with "keyboard" in the name and note down the id. Then type "xinput test TheID" (replacing "TheID" with the id you noted). Now start typing into some other application like your browser address bar. You'll see that in the terminal it is noting down the character code for every key you press.
So I thought to myself, why should I allow Dropbox to potentially attack my X11 session in this way? And more than that, why should I allow it to have access to read and write any file belonging to user "mike"? The first thing I did was create a new password-less user on the system named "mike.dropbox". Under the Terminal program on the Ubuntu desktop run the following:
sudo adduser --force-badname mike.dropboxThe --force-badname option was required because it complains about the full stop in the username otherwise. You can use whatever username/format you want though.
The next step was to set up Dropbox under that new user. First of all, I needed to give the user "mike.dropbox" temporary access to X11 so I could access the installation GUI as that user. To do this I ran:
xhost +SI:localuser:mike.dropbox
Then I su'd to the "mike.dropbox" user and ran the dropbox executable:
sudo su -s /bin/bash mike.dropbox dropbox start
At this point, you go through the normal installation process, entering your Dropbox credentials and so on. The next steps are to stop Dropbox, remove X11 access for the "mike.dropbox" user and then restart it. Run the following command as your "mike.dropbox" user:
dropbox stop
And then the following command as your "mike" user:
xhost -SI:localuser:mike.dropbox
And finally, the following command as your "mike.dropbox" user:
dropbox start
At this point, it might be a good idea to configure up the system to start Dropbox when it boots up. You can do this by creating a cron job entry for the "mike.dropbox" user which looks like this:
@reboot dropbox start &>/dev/null
You might also want to test Dropbox at this point to make sure it's working. To do this, try adding/removing some files in "/home/mike.dropbox/Dropbox/" and check to see if the changes propagate to your other Dropbox clients. If you don't have any other Dropbox clients configured, you can use the web interface.
You might be thinking now that a "/home/mike.dropbox/Dropbox/" folder which is completely inaccessible to user "mike" is not a lot of use. You might have thoughts about adding the "mike" user to the "mike.dropbox" group, and fiddling with permissions. That is not going to work out well; the dropbox executable will want to create new files owned by "mike.dropbox" only. So what I did next was an "apt-get install samba smbfs". The idea was to export the folder as a network mount, mounting it at "/home/mike/Dropbox/". You can probably use NFS for this too. In my /etc/samba/smb.conf I added:
[dropbox] comment = Mikes Dropbox path = /home/mike.dropbox/Dropbox guest ok = no create mask = 0600 directory mask = 0700 valid users = mike.dropbox read only = no
And then restarted samba with a, "service smbd restart". I then added a "mike.dropbox" user to samba by running the following command as root, and picking a long random password:
smbpasswd -a mike.dropbox
I then created a directory at /home/mike/Dropbox/ and put a file named "credentials" in it containing the following:
user=mike.dropbox pass=The_long_random_password_I_just_chose_in_the_previous_step
In my /etc/fstab I then added the following new entry:
//localhost/dropbox /home/mike/Dropbox smbfs defaults,noexec,nosuid,user,uid=1000,gid=1000,
credentials=/home/mike/Dropbox/credentials 0 0
The uid and gid should be set to whatever the uid and gid are for your equivalent of the "mike" user. The noexec and nosuid bits are optional. They add a bit more security (see "man mount"). Finally, you need to run a "mount ~/Dropbox/" as the "mike" user. You will only need to do this the first time. On subsequent reboots it will be mounted automatically.
So now we have a /home/mike/Dropbox/ folder, full of files which appear to be owned by the "mike" user, syncing with the Dropbox cloud, just as before. The only "negative" difference is that we don't get the GUI magic which allows us to see the status of file transfers and such. But now the dropbox process is isolated under the "mike.dropbox" user, it can no longer connect to my X11 session to sniff my key presses, and it can no longer read/write any of the files owned by my main user.
More File Permissions
Ok, so the Dropbox process can no longer read/write any files owned by user "mike". It can still read any globally readable files on the system though and data from volumes like /proc/. Why though? There are only a very limited number of files that it needs to be able to read and write in order to operate. To restrict the process to only being able to read and write certain files, I created an AppArmor profile. Amongst other things, AppArmor allows you to limit an application so it can only read and write certain whitelisted files. Non Debian based systems probably want to use SELinux for this instead. There are plenty of AppArmor tutorials out there, so I wont go into details on how to use it. Basically, you use the command "aa-genprof" on /usr/bin/dropbox to collect a list of which files it accesses and how it accesses them, and you store that list in a special format in /etc/apparmor.d/. Any attempted violations are blocked and logged to /var/log/kern.log.
Quotas
My Dropbox allowance is 8.5GB. So why would I allow the Dropbox application the opportunity to use up more than 8.5GB of disk space on my laptop? It could potentially DOS the system, either maliciously or accidently. So I've implemented filesystem quotas. I'm using ext4, and I have a single / partition so YMMV. First of all I added the options "usrquota,grpquota" to the "/" mount point in /etc/fstab and remounted it with a "mount / -o remount". Then I enabled disk quotas by running the following two commands:
quotacheck -cavugm quotaon /
This might take a while to run as it has to calculate the current usage of every user on the system. I then ran the following command to limit the "mike.dropbox" user to ~10GB of space only:
quotatool -bu mike.dropbox -l 10000MB /
I know I said "8.5GB", but I suspect the Dropbox application needs storage for other purposes as well so I've given it some leeway. Now if I want to see the quota and usage for user "mike.dropbox", I can simply do this:
root@laptop:~# quota -u mike.dropbox
Disk quotas for user mike.dropbox (uid 1005):
Filesystem blocks quota limit grace files quota limit grace
/dev/mapper/cryptdisk
288188 0 10240000 2660 0 0
root@laptop:~#
You can see from the output above, that the
"mike.dropbox" user is using about 288MB of disk space on "/" currently,
and has an allowance of about 10GB.Network Permissions
Another good thing about isolating applications to run under unique uids, is that iptables allows you to specify outgoing firewall rules on a per user basis. If for example, I wanted to block Dropbox from connecting to the Internet all together (I obviously don't), I could simply run the following command as root:
iptables -A OUTPUT -m owner --uid-owner mike.dropbox -j REJECT
I initially tried to collect a list of IPs that Dropbox was connecting to, by monitoring the output of "netstat -anp". The idea was going to be that I blocked "mike.dropbox" from making any outgoing connections other than to a list of approved IPs on approved ports. I quickly realised that this was going to be difficult and error prone; it makes connections to multiple IPs in Amazons cloud, some of which I expect will change over time. You may want to try this though, so I thought I'd mention it. It's also worth noting that Dropbox broadcasts packets to the network using UDP when Lan Sync is enabled, so if you want that to continue, you'll want to allow that traffic.
Even though I decided against this sort of blocking, I still wanted to do something interesting to the Dropbox traffic. I have Tor running on my laptop. If I could use Tor to connect to the Dropbox cloud, that would afford me some privacy. This should be safe, as the Dropbox traffic is all secured using encryption, so it isn't possible for a Tor Exit node to MITM it. Doing this would prevent Dropbox from maintaining a log of my whereabouts (IP addresses and times) at least. I editted my /etc/tor/torrc, added the following two lines, and then restarted Tor:
TransPort 9040 DNSPort 5300
I then added the following additional firewall rules:
iptables -t nat -A OUTPUT -m owner --uid-owner mike.dropbox -p tcp -j REDIRECT --to-ports 9040 iptables -t nat -A OUTPUT -m owner --uid-owner mike.dropbox -p udp --dport 53 -j REDIRECT --to-ports 5300 iptables -A OUTPUT -m owner --uid-owner mike.dropbox -p tcp -d 127.0.0.1 --dport 9040 -j ACCEPT iptables -A OUTPUT -m owner --uid-owner mike.dropbox -p udp -d 127.0.0.1 --dport 5300 -j ACCEPT iptables -A OUTPUT -m owner --uid-owner mike.dropbox -j REJECT
Now all traffic from any applications running under the "mike.dropbox" user id, are forced to route their network traffic through Tor. This even includes DNS lookups. You can read more about using Tor's Transparent Proxy mode at https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy
File Encryption
Despite what Dropbox says, they can read the files which you store in your Dropbox folder. The only way to prevent them being able to do that, is by handling the encryption on the client side. Luckily, on Linux this is easy. Do an "apt-get install encfs" and then run the following:
encfs ~/Dropbox/Encrypted/ ~/SecureDropbox/
The first time you run it, you will be asked a couple of questions to initialise the encrypted mountpoint. Once it has finished, you will have a directory called "~/SecureDropbox/". When you make any changes to that directory, they are mirrored to "~/Dropbox/Encrypted/", except they are encrypted before hand. Don't touch any files in "~/Dropbox/Encrypted/", only in "~/SecureDropbox/". There is one encrypted file per real file. If you unmount it with a "fusermount -u ~/SecureDropbox/" the files will disappear from that directory, but they will still be in their encrypted form in "~/Dropbox/Encrypted/". You can run the same encfs command as above to remount "~/SecureDropbox/". This time it will just ask you to re-enter the password that you initially provided.
If you want the whole of your Dropbox to be encrypted, rather than just a single folder, you could maybe change your /etc/fstab to mount your Dropbox at "~/.Dropbox.unencrypted" instead of "~/Dropbox/" and place your encfs mount at "~/Dropbox/" instead. The problem with this is, you wont be able to access encrypted files from other devices that don't support encfs.
Saturday, April 12, 2014
Self stirring mug
Wouldn't it be much easier to stir your tea if your mug had a spring winding to stir the tea under it?
Thursday, April 10, 2014
Varying passwords for each service without memorizing
It's a good practice to use different passwords on each single service you use so that if one of the services is compromised due to any reason, the hacker is not able to hijack your whole internet identity. Such a practice might come in handy for those changing their passwords in wake of the heartbleed bug.
There can be quite a few ways to do this (and you can invent your own as well, share in the comments if you like).
1. Categorizing:
Categorize your passwords for each type of service. A unique password for the primary email address (which you should change every now and then), a single password for the social media (Facebook, Twitter, whatever-you-use etc) and another password for, for example, your secondary email addresses or your work / academic addresses. This method categorizes different types of services and protects you from anyone who has found one of those passwords from moving on to other types. Something of the sort done in space stations and submarines; section wise protection so that even if one section is breached, others remain safe.
2. Variation:
If you find even categorizing difficult to memorize you can go for this method. To vary passwords, you can choose a formula that bases the variation on a theme. Decide a core password of a mixture of six letters and numbers (alpha-numeric) that are not any dictionary word... say xYz123.
Now, all your passwords for different websites or services can be variations on that core password, and you don't have to remember a separate password for each service and yet actually use a different one for every single one of them.
For example, you can pick the last two letters of the service's name, so that even if your password is viewed or compromised one can not tell what the ending letters are, and place them at the start and end of your core password. So if you are using Gmail, the letters are “i” and “l" which come at the start and end of your core password which would now be ixYz123l. For Facebook, your password would be oxYz123k ("o" and "k" - the last two letters - at start and end).
You can, ofcourse, make this a much easier variation by just adding them to the end of your core password or, perhaps, make even more obscure by making your variation formula / scheme more complex and adding the letters somewhere in the middle or at two places of your core password. Depends on how good you are with words.
--
And on top of all, it is always better to keep a unique, unrelated, password for your primary email address so that there's always somewhere you can go and use a "forgot my password" option making it your last line of defense.
All the chicken you need
The best Game of Thrones meme KFC could have made with reference to the first episode of the fourth season with hound claiming rights to all the chicken in the bar.
Wednesday, April 9, 2014
Tuesday, April 8, 2014
Subscribe to:
Posts (Atom)