Saturday, 10 May 2014

How to sending thousands of emails from your server to your subscription list.

OK I wrote one for work and it sends about 10 million emails a month.

First you need to know and understand that php can write command line programs


1) You need to have a subscription database with email addresses of those that you will email

2) You need a table called for example eBlastAddresses that table just needs a UID, the id of the email that will be sent and the email address it will go to.

3 Write a script that will do the following steps

a) Check if any email addresses are in the eBlastAddresses table for the email you want to send if none exist then extract out of your subscription list the list of emails address to send and put them in the eBlastAddresses table.

b) Write a loop that will extract the next 1000 emails to send then, mark them as processing and send them

c) When the 1000 have been sent then delete all those marked as processing from the eBlastAddresses table. then go to step b

d) When all emails have been sent end program

Job done.

It takes about 4-5 hours from memory to send 300k emails.

If the job crashes you can just restart and extract the next 1000 emails this will mean that you won't be sending multiple emails to people if it crashes and you have to start it again.

Saturday, 26 April 2014

Blogger apparently not compatible with chrome

Just opened blogger on my iPhone using chrome and was surprised to see the following message. Screen grab of Blogger interface on Chrome iPhone 5

Friday, 25 April 2014

SQL Studio for Mac OS X

Today I was very pleased to find an affordable SQL Studio for Mac OS X.  I logged into a MSSQL Server and did a few tests.  Its quite basic at the minute but they promise lots of updates.  I'm looking forward to seeing the updates that will come in the future.  The most important thing is that you can run SQL Statements.

Saturday, 29 March 2014

Mac Pro Sun Spider results

Ok so I was in the Apple store this morning and just as I was leaving I decided to ask when they would have the new MacPro in.  The girl at the door smiled and said its right over there.  So I only had a moment to run the SunSpider tests on it using Safari. I had previously ran the same tests on my Mac Book Air and the new iMac you can find the results here, since I only had moments so I quickly posted my results here.  I must admit that the photos of the Mac Pro are to me nicer that the reality but then again I was more interested in the functionality.  I would like to have had time to put Steam on to the MacPro and play BlackOps just to see how responsive the graphics are because I really am pushing them on my MacBook Air. 

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 112.1ms +/- 0.6%
--------------------------------------------

  3d:                   17.4ms +/- 2.1%
    cube:                6.0ms +/- 0.0%
    morph:               5.0ms +/- 0.0%
    raytrace:            6.4ms +/- 5.8%

  access:               10.7ms +/- 3.2%
    binary-trees:        1.0ms +/- 0.0%
    fannkuch:            4.7ms +/- 7.3%
    nbody:               2.0ms +/- 0.0%
    nsieve:              3.0ms +/- 0.0%

  bitops:                5.1ms +/- 4.4%
    3bit-bits-in-byte:   1.0ms +/- 0.0%
    bits-in-byte:        1.1ms +/- 20.5%
    bitwise-and:         1.0ms +/- 0.0%
    nsieve-bits:         2.0ms +/- 0.0%

  controlflow:           1.0ms +/- 0.0%
    recursive:           1.0ms +/- 0.0%

  crypto:                9.0ms +/- 0.0%
    aes:                 5.0ms +/- 0.0%
    md5:                 2.0ms +/- 0.0%
    sha1:                2.0ms +/- 0.0%

  date:                 14.0ms +/- 0.0%
    format-tofte:        8.0ms +/- 0.0%
    format-xparb:        6.0ms +/- 0.0%

  math:                  8.5ms +/- 5.9%
    cordic:              2.0ms +/- 0.0%
    partial-sums:        5.3ms +/- 6.5%
    spectral-norm:       1.2ms +/- 25.1%

  regexp:                6.4ms +/- 5.8%
    dna:                 6.4ms +/- 5.8%

  string:               40.0ms +/- 1.2%
    base64:              3.0ms +/- 0.0%
    fasta:               6.3ms +/- 5.5%
    tagcloud:            8.5ms +/- 4.4%
    unpack-code:        17.2ms +/- 1.8%
    validate-input:      5.0ms +/- 0.0%

Friday, 7 February 2014

Tricking hackers when they are trying to brute force passwords.

Just finished listening to the Security Now Episode number 441 podcast with Steve Gibson & Leo Laporte which was about passwords their minimum lengths and complexity of a list of top one hundred retail stores online. The basic premise of the podcast was about the security or lack of it that the top 100 commercial online companies were using. I was glad to hear that Apple did really well. Annoyed that it turns out that Amazon did so badly. Amazon along with a whole pile of others would allow hackers as many attempts at cracking your password as they want while Apple, Microsoft and a few others would restrict your attempts to ten attempts. Honestly you need to listen to the podcast - Security Now.

The first part of this post is about the podcast led me to the conclusion that I'm not sure if you are actually doing the right thing when you let a hacker know you are NOT ALLOWING them to brute force a password. Here is my reasoning if you let a hacker know that you have blocked the account you are technically passing useful information back to the hacker. This is because we check each password that is passed to the server in order. And that is the flaw in the process for example you don't tell a hacker that the username was not found. You say generic statements like "Sorry that username/password was not recognized" so the hacker doesn't know if its the password or the username they are using.

One of the latest functions in PHP "password_hash" allows for checking passwords and to tell the function how expensive the CPU cost will be for each checked password.

So what if we not only used this type of expensive password checker but we changed the system to record the last request from a specific IP address for a specific account and made the time between checking be say one second. This will then allow the server to ignore any extra requests and just return a fail message as a hacker would not know that load of the requests were ignored so they might go straight past the correct password. Because the one second time limit on the server had not expired while for the human user they might miss the time limit a couple of times but would eventually pause in typing their passwords. Now we could add in a lock mechanism after 10 failed attempts that the server actually tested (emailing the clients email address to tell them its blocked) but not updating the screne to say the account is locked. Hackers would think that they can test maybe 1000's of passwords.

The second part of this post is when Steve & Leo were talking about the strength of passwords you know those little coloured bars that appear beside the password field to tell you how strong or weak a password. the problem with most of these is that they basically work on the principle that the developer that created it builtin so for example a strong password 4 years ago could be considered weak now. When Leo and Steve were suggesting that every site should use these I was screaming no!!!! If the site implements a javascript widget that will show you this how often is it updated? once a year twice? How often will the sites that implemented it think about updating it.

Thats why I came up with one that would self update. I announced it in a previous post "Password Security how long will a hacker take to crack your passwords" a javascript plugin that would tell you how long it should take a hacker to crack your password.  It works out how complex it should make the calculation based on the current year.  It attempts to calculate the number of hashes per second that a computer could compute and then works out the complex nature of the password you just added then does the math and tells you much time it will take to hack.