Random thoughts

As if dropping your beloved password manager and starting with another product wasn't hard enough, there is also the challenge of moving credentials to a new system. For many years I have been a happy RoboForm customer. The password manager integrated nicely with all browsers I use, had an easy to use interface and a flexible password generator, and with some fiddling also allowed selectively sharing family passwords on some computers only.

Photo credit: Image by Jan Alexander from Pixabay

The integration with Firefox deteriorated when legacy extensions were dropped from the browser, and the new RoboForm extension never quite reached the same ease of use and consistency in the user interface. Time had come to look into alternatives, and the choice was a combination of KeyPass, the the popular open source product, and 1Password, an the enterprise ready solution that supports shared vaults for families and teams.

The migration seemed easy: RoboForm does have CSV export capabilities, although somewhat hidden in the latest version, and 1Password claims the ability to import RoboForm CSV files, only after a few attempts the results were mixed, to say the least. Some userids ended up in the password fields, and multiline notes were interpreted as tags. Clearly something wasn't right. 1Password support explained that the format seems to have changed recently, with RoboForm now exporting cards with the fields ordered as


whereas 1Password expects


That's where my new affection for PowerShell comes into play. This would have entirely doable in REXX, Perl, Python or any other language I have used for reformatting data, but parsing and generating CSVs can be tricky to implement or require additional modules. Not so in PowerShell, where the conversion from an arbitrarily ordered CSV with headers is a simple one-liner:


And voilà, all data automagically ends up in the right fields.

Labels: powershell, security, technology

Some twenty developers and security experts gathered at the Stockwork Coworking Space for today´s joint Vienna DevOps & Security and System Architects Group meetup http://meetu.ps/2v2DGg.

Best practices for AWS Security

Philipp Krenn (@xeraa) nicely explained the fundamental risks of AWS services:
Starting services on AWS is easy. So is stopping.

Recent incidents show that a compromised infrastructure can cause more than short disruptions. Several companies went out of business when not only their online services but also data stores and backups were gone:

• Code Spaces goes dark after AWS cloud security hack
• DrawQuest permanently shuts down after security breach
• Bonsai.io suffers from an AWS security incident

(Some) recommendation for using AWS services:

• Lock away the root account. Never use this account for service or action authentication, ever.
• Create an IAM user with a password policy for every service or action to limit damage in case an API key gets compromised.
• Use groups to manage permissions.
• Use two-factor authentication (2FA) using Google Authenticator.
• Never commit your credentials to a source code repository.
• Enable IP restrictions to limit who can manage your services even with an API key.
• Enable Cloudtrail to trace which user triggered an event using which API key.

Other cloud security providers may offer different security features

The (fancy!) slides are available here: https://speakerdeck.com/xeraa/i-am-what-iam-for-devops-vienna

ISO 27001 - Goals of ISO 27001, relation to similar standards, implementation scenarios

Roman Kellner, Chief Happiness Officer :-) at @xtradesoft, gave an overview of the ISO 27001 and related standards:

• ISO 27001:2013 Information Security Management System (ISMS) Requirements
• ISO 27002:2013 Code of Practice
• ISO 31000 Risk Management

Information security management is not limited to computer security; it is equally relevant for paper documents, human knowledge, etc.

The structure of ISO 27001 looks somewhat similar to ISO 9001 Quality Assurance, including the monitoring and continuous improvement loop of Plan-Do-Check-Act (PDCA).

For a successful implementation and certification, the ISO 27001 efforts must be supported and driven by the company leadership

The third talk about Splunk unfortunately had to be postponed.

Labels: cloud, events, itarchitecture, security, technology

IT security is not just about computers and smartphones any more. Your smart TV may be allow attackers to get access to sensitive information and control the device, as security start-up ReVuln demonstrates for Samsung's Smart TV.

Once simple stand-alone receivers, TV sets, set top boxes and digital recorders are full featured computers and connect to home networks for downloading program guides and software updates, sharing pictures and videos and enabling social media integration.

Read more about recently discovered security flaws in home entertainment equipment on The Register.

Labels: security, technology

Google recently announced plans to make search more secure.

This effort includes encrypting search queries, which is especially important when using an unsecured Internet connection or accessing the Internet through intermediate devices which have the ability to log requests. Encrypting the search interface will automatically block referrer information for unencrypted sites, and would provide an incentive for companies to join the industry effort to use SSL/TLS encryption more widely.

But Google takes this a step further, hiding query information from encrypted searches. The click-through tracking link for unencrypted search includes the search term parameter “q”, which gets passed to the visited website:
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&frm=1&url=http%3A%2F%2Fexample.com%2F

The link for encrypted search, however, leaves the parameter “q” empty. Interestingly click-throughs for encrypted searches are tracked on an unencrypted connection, thus revealing the visited site address to an eavesdropper:
http://www.google.com/url?sa=t&rct=j&q=example&url=http%3A%2F%2Fexample.com%2F

With this change, the visited website receives no information about the search term. What enhances privacy for searchers holds website owners off important information for optimizing their websites to best serve visitors.

Browsers already provide mechanisms for controlling referrer information, for example the network.http.sendRefererHeader preference setting or the customizable RefControl extension for Firefox. Google’s privacy enhancement takes control away from the users by not passing referring information, period.

Google’s move has the potential to change the search engine marketing (SEM) landscape. Search terms in paid ads will remain trackable unchanged. For organic search, the only way for website owners to get access to, albeit delayed, aggregated and limited to the top 1,000, search terms is through Google webmaster console, a very fine tool but not a replacement for an integrated web analytics solution.

The impact of this change goes beyond web analytics and search engine optimization (SEO): Sites often use the search terms that led visitors to the site for dynamic customization, offering related information and links. With encrypted search, visitors will no longer have access to these enhancements either.

Labels: google, metrics, security, seo

The disputed presidential elections in Iran reminded me of an observation a few weeks ago when the European Union held elections for the European Parliament.

Absentee voting, and mail voting in particular, present some interesting security and privacy challenges. For the European election, voters who wanted to cast their vote outside of their electoral district could request absentee ballots to vote in other districts or by mail. In a commendable effort to make voting as convenient as possible, the administration only required name, address and passport number for requesting absentee ballots and delivered them to voters by regular mail, leaving ample room for misuse already.

But I was unpleasantly surprised when I found a sticker(!) on my mailbox indicating that “important electoral mail” had been delivered:



Well intended for sure, but in my opinion the service orientation really went overboard here. With all the trust in the administration, the electoral process and the people in our neighborhood, privacy and security concerns should be considered.

Labels: austria, security

Tavis Ormandy has posted a potential security exposure with DNS entries for "localhost" in zone files on Bugtraq. While the impact of this exposure seems minimal, I would rather err on the side of caution, and this should be fairly easy to fix.

"localhost" DNS records in a domain should not be confused with the ".localhost" TLD defined in RFC 2606 Reserved Top Level DNS Names, and should be configured on nameservers. I haven't been able to find a requirement in the RFCs to have a "localhost" entry in a domain, nor can I think of a compelling reason for keeping the entry as long as nameservers for a domain are properly configured to handle queries for "localhost.".

RFC 1912 Common DNS Errors explains how to configure the localhost and 0.0.127.in-addr.arpa zones:

The "localhost" address is a "special" address which always refers to
the local host.  It should contain the following line:

           localhost.      IN      A       127.0.0.1

The "127.0" file should contain the line:
           1    PTR     localhost.

and recommends to not define "localhost" with the domain name appended.

Thoughts on removing "localhost" from zones, anyone?

Labels: security, technology

While sitting at Vienna airport and waiting for my flight to New York, a newspaper article about a security startup caught my attention: The Swiss company Wabisabilabi has established a market place for security exposures with the intent to give security experts "fair compensation for their discoveries".

Googling for the easy to remember company name (Vienna airport now has wireless connectivity and unlike other airports this is offered for free, nice!) I stumble across a good number of articles which sound very similar to the press release, I mean, article I just read ... becoming the EBay of zero-day exploits, finally a market place for security issues.

The first two search results are obviously the new site that's going to make the world more secure. Not that they have figured out how to give pages meaningful titles yet:

On to the press release at https://www.wslabi.com/wabisabilabi/news.do -- mistakes happen but finding a typo in the first press release of a company looks odd. Equally odd is their math: "Recently it was reported that although researchers had analyzed a little more than 7,000 publicly disclosed vulnerabilities last year, the number of new vulnerabilities found in code could be as high as 139,362." Exactly 139,362, huh?

Not much information about the company either, looks like a British Limited company although there is no company registration information on the site (or at least I haven't found it). I guess I will sign up anyway and see what they have to offer.

Labels: security, technology

developer.com ran an article about AJAX security, the title of which caught my attention. The suggestions the author makes, however, are either obvious (use a well-tested framework instead of writing your own code) or plain wrong (pretty much the rest of the suggestions). Michael Baierl has commented in detail about what's wrong with this article.

Another unfortunate case of security by obscurity.

Labels: security, webdevelopment