We know passwords aren't great and that people choose crappy short ones that are easily remembered given half the chance. The solution to which seems to be to ask for a least one number, one upper case char, one symbol and a minimum of 8 chars...
However, you don't want to use the same password everywhere as the majority of sites aren't trustworthy* so it's foolish to use the same password on all of them. The result is an ever mounting litter of passwords that you can't remember and either end up writing them down (which likely violates terms of service and makes you liable in the event of abuse) or rely on "forgotten password mechanisms" to log in as and when needed (the main frustration here being turnaround-time and the need to come up with a new bloody password each time).
Yet using 3 or more words as a passphrase is more secure than a short forgettable password and would make a website a damn sight easier to use - you still can't use the same password everywhere though. It's about time we started making minimumpasswordlength 16 characters and dismiss the crypto garbage rules that don't help anyone.
Facebook, Google and the like would have you use their Open ID Connect services - this way they effectively own your online identity - and, if you do use them, the multi-factor authentication (MTA) options are well worth adopting. Personally I don't want these guys to be in charge of my online identity though (and most organisations won't be either) so whilst it's ok to provide the option you can't force it on people.
We need to continue to support passwords but we need to stop with these daft counterproductive restrictions.
* Ok, none of them are but some I trust more than others. I certainly won't trust some hokey website just because the developers provide the illusion of security by making my life more complicated than is necessary.
2015/06/22
2015/06/20
Jenkins on Raspberry Pi 2
I had an old Raspberry Pi which was fun to play with but really too underpowered to do much with. However, I recently took part in the BCS Womens App-athon World Record attempt where I had a chat with a guy about Pis and running Minecraft and he pointed out the newer Pi2 was quite capable of running MCServer (a C++ implementation of a Minecraft Server).
But I wanted a Pi2 for something more serious - something running Jenkins to manage the various bits of codes I knock up. I'd tried this on the original Pi but it was unusable...
Install from instructions Random Code Solutions were ok but the version installed via apt-get was old and slow and couldn't easily be updated (managed package). I removed this and installed Tomcat 7 but this bizarrely used Java 1.6 and similarly wasn't easily changed...
Managed packages, they make life easy but you're dependent on them keeping things up to date.
So the process I finally used was:
1. Install Java 8, the Oracle version. This was already there on the version of Raspbian I was using.
2. Ensure this JVM is set as the default:
Should give you something like image below. Select the version corresponding to java 8...
3. Download Tomcat. Version 7.0.62 was the one I used.
4. Jenkins will complain about URI charset on startup so before installing change the URIEncoding parameter for Tomcat i18n in apache-tomcat-7.0.62/conf/server.xml to set the URIEncoding as UTF-8:
5. Startup Tomcat
Check this is running by hitting the server: http://{server}:8080/ and you should see something like below:
6. Download Jenkins (just grab the jenkins latest release though at time of writing the version I have is 1.617) and put this into the webapps folder under Tomcat. Or...
7. Tomcat will now deploy the WAR. This can take a little time and the easiest way to see it running is to run "top" and you should see Java consuming 100% CPU. When this drops to 0% it'll be done.
8. You should now be able to see Jenkins running on http://{server}:8080/jenkins/ (on my network it's called raspberrypi2 - genius huh!).
All done! Kind of, it's best to update all plugins and restart, configure security, set access control and configure an email server for alerting.
A simple task runs ok and Jenkins is quite responsive when nothing else is running on the server...
I can run MCServer ok at the same time but Jenkins gets slow when the world is in use. Otherwise no issues yet though I suspect as I add more jobs it'll probably run out of RAM. We shall see. Perhaps I'll be buying another one of these Pi2's; wife will be pleased.. ;)
But I wanted a Pi2 for something more serious - something running Jenkins to manage the various bits of codes I knock up. I'd tried this on the original Pi but it was unusable...
Install from instructions Random Code Solutions were ok but the version installed via apt-get was old and slow and couldn't easily be updated (managed package). I removed this and installed Tomcat 7 but this bizarrely used Java 1.6 and similarly wasn't easily changed...
Managed packages, they make life easy but you're dependent on them keeping things up to date.
So the process I finally used was:
1. Install Java 8, the Oracle version. This was already there on the version of Raspbian I was using.
2. Ensure this JVM is set as the default:
update-alternatives --config java
Should give you something like image below. Select the version corresponding to java 8...
3. Download Tomcat. Version 7.0.62 was the one I used.
cd /usr/local/bin
wget http://www.mirrorservice.org/sites/ftp.apache.org/tomcat/tomcat-7/v7.0.62/bin/apache-tomcat-7.0.62.tar.gz
tar -zxf apache-tomcat-7.0.62.tar.gz
4. Jenkins will complain about URI charset on startup so before installing change the URIEncoding parameter for Tomcat i18n in apache-tomcat-7.0.62/conf/server.xml to set the URIEncoding as UTF-8:
<Connector port="8080" URIEncoding="UTF-8"/>
5. Startup Tomcat
/usr/local/bin/apache-tomcat-7.0.62/bin/startup.sh
Check this is running by hitting the server: http://{server}:8080/ and you should see something like below:
6. Download Jenkins (just grab the jenkins latest release though at time of writing the version I have is 1.617) and put this into the webapps folder under Tomcat. Or...
wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war -O /usr/local/bin/apache-tomcat-7.0.62/webapps/jenkins.war
7. Tomcat will now deploy the WAR. This can take a little time and the easiest way to see it running is to run "top" and you should see Java consuming 100% CPU. When this drops to 0% it'll be done.
8. You should now be able to see Jenkins running on http://{server}:8080/jenkins/ (on my network it's called raspberrypi2 - genius huh!).
All done! Kind of, it's best to update all plugins and restart, configure security, set access control and configure an email server for alerting.
A simple task runs ok and Jenkins is quite responsive when nothing else is running on the server...
I can run MCServer ok at the same time but Jenkins gets slow when the world is in use. Otherwise no issues yet though I suspect as I add more jobs it'll probably run out of RAM. We shall see. Perhaps I'll be buying another one of these Pi2's; wife will be pleased.. ;)
2015/06/18
Power to the People
Yesterday I received my usual gas and electricity bill from my supplier with the not so usual increase to my monthly direct debit of a nice round 100%! 100% on top of what is already more than I care for... joy!
What followed was the all too familiar vent-spleen / spit-feathers etc. before the situation was resolved by a very nice customer services representative who had clearly seen this before... humm..
So, as I do, I ponder darkly on how such a situation could have arisen. And as an IT guy, I ponder darkly about how said situation came about through IT (oh what a wicked web we weave)... Ok, so pure conjecture, but this lot have previous...
100%! What on earth convinced them to add 100%? Better still, what convinced them to add 100% when I was in fact in credit and they had just reimbursed me £20 as a result?...
Customer service rep: It's the computers you see sir.
Me: The computers?
CSR: Well because they reimbursed you they altered your direct-debit amount.
Me: Yeah, ok, so they work out that I'm paying too much and reduce my monthly which would kind of make sense but it's gone up! Up by 100%!
CSR: Well er yes. But I can fix that and change it back to what it was before...
Me: Yes please do!
CSR: Can I close the complaint now?
Me: Well, you can't do much else can you? But really, you need to speak to your IT guys because this is just idiotic...
(more was said but you get the gist).
So, theories for how this came about:
If 1 or 2 then sack the idiots who came up with such a complete mess - probably the same lot who dream up energy pricing models so a "win-win" as they say!
If 3 then, well, shit happens. Bugs happen. Defects exist; god knows I've been to root-cause of many...
It's just that this isn't the first time, or the second, or the third...
(start wavy dreamy lines)
The last time they threatened to take me to court because I wouldn't let their meter maid in when they'd already been and so hadn't even tried again.. and since they couldn't reconcile two different "computer systems" properly it kept on bitching until it ratcheted up to that "sue the bastards" level. Nice.
(end wavy dreamy lines)
... and this is such an simple thing to test for. You've just got to pump in data for a bunch of test scenarios and look at the result - the same applies to that beastly matrix! ... or you've got to do code reviews and look for that "if increase < 1.0 then surely it's wrong and add 1.0 to make it right" or "increase by current/current + (1.0*current/current)".
So bad test practices and/or bad coding practices - or I could also accept, really bad architecture which can't be implemented, or really bad project management which just skips anything resembling best practices, or really bad leadership which doesn't give a toss about the customer - and really bad operations and maintenance regardless because they know they've got some pretty basic problems and yet they clearly can't help themselves to get it fixed.
It all comes down to money and with practices like this they'll be losing customers hand over fist (they do have the worst customer sat ratings apparently).
They could look at agile, continuous-integration, test automation, dev-ops, TDD and BDD practices as is the rage but they need to brush away the fairy dust that often accompanies these concepts (concepts I generally support incidentally) and realise this does not mean you can abandon all sanity and give up on the basic principles of testing and coding!
If anything these concepts weigh even more heavily on such fundamentals - more detailed tracking of delivery progress and performance, pair-programming, reviewing test coverage, using tests to drive development, automating build and testing as much as can be to improve consistency and quality, getting feedback from operational environments so you detect and resolve issues faster, continuous improvement and so on.
Computer systems are more complex and more depended on by society then ever before, they change at an ever increasing rate, interact in an constantly changing environment with other systems and are managed by disparate teams spread across the globe who come and go with the prevailing technological wind. Your customers and your business relies on them 100% to, at best, get by, and at worst, to exist. You cannot afford not to do it right!
I'm sure the issues are more complex than this and there are probably some institutionalised problems preventing efficient resolution mores the pity. But hey, off to search for a new energy provider...
What followed was the all too familiar vent-spleen / spit-feathers etc. before the situation was resolved by a very nice customer services representative who had clearly seen this before... humm..
So, as I do, I ponder darkly on how such a situation could have arisen. And as an IT guy, I ponder darkly about how said situation came about through IT (oh what a wicked web we weave)... Ok, so pure conjecture, but this lot have previous...
100%! What on earth convinced them to add 100%? Better still, what convinced them to add 100% when I was in fact in credit and they had just reimbursed me £20 as a result?...
Customer service rep: It's the computers you see sir.
Me: The computers?
CSR: Well because they reimbursed you they altered your direct-debit amount.
Me: Yeah, ok, so they work out that I'm paying too much and reduce my monthly which would kind of make sense but it's gone up! Up by 100%!
CSR: Well er yes. But I can fix that and change it back to what it was before...
Me: Yes please do!
CSR: Can I close the complaint now?
Me: Well, you can't do much else can you? But really, you need to speak to your IT guys because this is just idiotic...
(more was said but you get the gist).
So, theories for how this came about:
- Some clever-dick specified a requirement that if they refund some money then claw it back ASAP by increasing the monthly DD by 100%!..
- A convoluted matrix exists which is virtually impossible to comprehend; a bit like their pricing structure, which details how and when to apply various degrees of adjustment to DD amounts and has near infinite paths that cannot be proven via any currently known mathematics on the face of this good earth.
- A defect exists somewhere in the code.
If 1 or 2 then sack the idiots who came up with such a complete mess - probably the same lot who dream up energy pricing models so a "win-win" as they say!
If 3 then, well, shit happens. Bugs happen. Defects exist; god knows I've been to root-cause of many...
It's just that this isn't the first time, or the second, or the third...
(start wavy dreamy lines)
The last time they threatened to take me to court because I wouldn't let their meter maid in when they'd already been and so hadn't even tried again.. and since they couldn't reconcile two different "computer systems" properly it kept on bitching until it ratcheted up to that "sue the bastards" level. Nice.
(end wavy dreamy lines)
... and this is such an simple thing to test for. You've just got to pump in data for a bunch of test scenarios and look at the result - the same applies to that beastly matrix! ... or you've got to do code reviews and look for that "if increase < 1.0 then surely it's wrong and add 1.0 to make it right" or "increase by current/current + (1.0*current/current)".
So bad test practices and/or bad coding practices - or I could also accept, really bad architecture which can't be implemented, or really bad project management which just skips anything resembling best practices, or really bad leadership which doesn't give a toss about the customer - and really bad operations and maintenance regardless because they know they've got some pretty basic problems and yet they clearly can't help themselves to get it fixed.
It all comes down to money and with practices like this they'll be losing customers hand over fist (they do have the worst customer sat ratings apparently).
They could look at agile, continuous-integration, test automation, dev-ops, TDD and BDD practices as is the rage but they need to brush away the fairy dust that often accompanies these concepts (concepts I generally support incidentally) and realise this does not mean you can abandon all sanity and give up on the basic principles of testing and coding!
If anything these concepts weigh even more heavily on such fundamentals - more detailed tracking of delivery progress and performance, pair-programming, reviewing test coverage, using tests to drive development, automating build and testing as much as can be to improve consistency and quality, getting feedback from operational environments so you detect and resolve issues faster, continuous improvement and so on.
Computer systems are more complex and more depended on by society then ever before, they change at an ever increasing rate, interact in an constantly changing environment with other systems and are managed by disparate teams spread across the globe who come and go with the prevailing technological wind. Your customers and your business relies on them 100% to, at best, get by, and at worst, to exist. You cannot afford not to do it right!
I'm sure the issues are more complex than this and there are probably some institutionalised problems preventing efficient resolution mores the pity. But hey, off to search for a new energy provider...
Subscribe to:
Posts (Atom)