Saturday, September 22, 2012

No More Passwords

Too many websites have been breached in the past 24 months: 21 Sony sites, Gawker, and most recently LinkedIn. A minimum of 20 million passwords were leaked causing chaos on the Internet, from increase in spam originating from legitimate email accounts, to stolen credit cards used for money laundry from stolen emails attached to Amazon, PayPal, eBay and other online payment systems and stores.

This is an article showing what password crackers have done with all those leaked passwords; in summary: Minimal work is now needed to crack 90% of passwords in less than 24 hours!!!

Users are stupid. Fact well established thanks to all those leaks, where users have used the same password for their accounts as the email password. But, for the website developers to also be a failure in understanding proper password hashing & encryption? This is the ultimate failure that users cannot see coming until it's too late.

So why are we relying on passwords still? I own accounts at least 15 different websites and I do not like the idea of Single Sign On where one password allows me to login to all of them. That's simply insecure & risky.

The answer is very simple: We don't need passwords in general. Websites should instead offer authorization/access codes in combination to email addresses to access content. Those codes are auto generated by the website, random, long (128+ characters), and most importantly, the user does not have to input any data nor remember anything. It's important to not tie the code to any user data (salting).

The only thing that needs a password is: Email and online payment systems. Everything else should send its auth code by email. When a user wants to login, they go to their email, open the email that has the code and copy/paste it to login.

In case a website is cracked, then users aren't at risk & the website maintainers can simply regenerate all auth codes and email them to the users.

As for now, I adopted the "make a silly temp password" method. I keep forgetting passwords on purpose and every time, I reset the password and enter a new temporary and random password, until website maintainers cut the crap and ditch this password scheme.

Tuesday, September 11, 2012

Review: Pretec 8GB microSD Card

I bought this 8GB class 10 microSD card that also comes with an adapter from newegg for $8 (free delivery when choosing 5-7 day delivery). Pretec is a Taiwanese company.

The microSD card comes pre-formatted as FAT16 and preloaded with software for Android from a company called NQ Mobile:

  • Mobile Security: Protects against mobile viruses, trojans and spyware
    • Free features: anti-malware, Contacts backup, System optimization, Privacy Protection (checks app permissions), Traffic Manager
    • Premium: Anti-theft, Virus database update
  • Mobile Manager: Suite of tools for managing phone-related functions
    • Free: Call Manager (block calls/SMS), Backup Contacts, Erase call history/SMS
    • Premium: Hidden private space, spam database update
  • Mobile Booster: Smartphone performance optimization
    • Free: Single-key optimization, Task monitor, traffic monitor, power monitor, software manager, file manager
The sd card also comes with a Windows application for photo recovery and free recovery of 25 pictures, after which you have to pay.

The default capacity is 7.5GB, and the used capacity by the apps above is 20MB. fdisk output:
fdisk -l /dev/sdc

Disk /dev/sdc: 7964 MB, 7964983296 bytes
91 heads, 18 sectors/track, 9497 cylinders, total 15556608 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            8192    15556607     7774208    6  FAT16

Writing 1GB to the sd card:

dd if=/dev/zero of=./test.dd bs=10M count=100
100+0 records in
100+0 records out
1048576000 bytes (1.0 GB) copied, 0.974053 s, 1.1 GB/s

Writing 100MB to the sd card with fdatasync enabled to avoid caching (realistic number for cameras):

dd if=/dev/zero of=./test.dd bs=10M count=10 conv=fdatasync
10+0 records in
10+0 records out
104857600 bytes (105 MB) copied, 8.36829 s, 12.5 MB/s

Writing 500MB to the sd card with fdatasync enabled:


dd if=/dev/zero of=./test.dd bs=10M count=50 conv=fdatasync
50+0 records in
50+0 records out
524288000 bytes (524 MB) copied, 63.5707 s, 8.2 MB/s

Putting ext4 instead of FAT16 on the card. First I changed the partition type using fdisk/cfdisk, then I used mkfs.ext4 with no options (defaults) on the partition.

mkfs.ext4 /dev/sdc1
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
486720 inodes, 1943552 blocks
97177 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1992294400
60 block groups
32768 blocks per group, 32768 fragments per group
8112 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                           
Writing inode tables: done                           
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
Now running the same write tests as above:

dd if=/dev/zero of=./test.dd bs=10M count=100             
100+0 records in
100+0 records out
1048576000 bytes (1.0 GB) copied, 0.698984 s, 1.5 GB/s

dd if=/dev/zero of=./test.dd bs=10M count=10 conv=fdatasync
10+0 records in
10+0 records out
104857600 bytes (105 MB) copied, 9.40124 s, 11.2 MB/s

dd if=/dev/zero of=./test.dd bs=10M count=50 conv=fdatasync
50+0 records in
50+0 records out
524288000 bytes (524 MB) copied, 42.9945 s, 12.2 MB/s

Now testing XFS file system:
mkfs.xfs -f /dev/sdc1
meta-data=/dev/sdc1              isize=256    agcount=4, agsize=485888 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=1943552, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

dd if=/dev/zero of=./test.dd bs=10M count=100              
100+0 records in
100+0 records out
1048576000 bytes (1.0 GB) copied, 0.590697 s, 1.8 GB/s

dd if=/dev/zero of=./test.dd bs=10M count=10 conv=fdatasync
10+0 records in
10+0 records out
104857600 bytes (105 MB) copied, 8.03924 s, 13.0 MB/s

dd if=/dev/zero of=./test.dd bs=10M count=50 conv=fdatasync
50+0 records in
50+0 records out
524288000 bytes (524 MB) copied, 42.0262 s, 12.5 MB/s


Unfortunately, there's no native exFAT driver for Linux so I cannot test the write speeds properly. exFAT is the filesystem used by some video cameras and is newer than FAT16.


In conclusion, the card does perform to the class 10 speed standards: a minimum of 10 MB/s. Your experience will vary depending on the filesystem you choose.

Note: Do not be fooled by the 1GB/s speeds. Those happened because my machine has l6GB RAM. Whenever a program writes to storage, the operating system will write to RAM then sync the data to disk, for the best performance. So, the more free memory you have, the better the performance.

Monday, September 3, 2012

Event: BarCamp Kuwait 4

The awesome @ahamshay has been able to get us another BarCamp event this year.

If you're not familiar with BarCamp, it's where we geeks gather and share our projects and demonstrate them (if possible).

If you'd like to attend, we'd appreciate it if you register so we can properly estimate the number of attendees & speakers.