Adding blog articles, associated images and authors for new blog entries (#77)

* add D Wehrle Blog Articles

* changing pub dates

* merging authors

* changed up authors.yml

* fixing copy paste problemo

* Change publish date of Hackathon blog post to today.

* Change publish date of Windows Hello blog post to Tuesday.

_data/authors.yml

@@ -72,3 +72,10 @@ esmaeil_sarabadani:
     name: Esmaeil Sarabadani
     email: esmaeil.sarabadani@haufe-lexware.com
     twitter: esmaeils
+daniel_wehrle:
+    name: Daniel Wehrle
+    email: daniel.wehrle@haufe-lexware.com
+    github: DanielHWe
+anja_kienzler:
+    name: Anja Kienzler
+    email: anja.kienzler@haufe-lexware.com

_posts/2016-08-12-SummerInterships.md

@@ -1,3 +1,31 @@
+<<<<<<< HEAD
+---
+layout: post
+title: Summer Internship @Haufe
+subtitle: An experience that greatly helped me to improve myself
+category: general
+tags: [culture, docker]
+author: Bogdan Bledea
+author_email: bogdan.b19c@gmail.com
+header-img: "images/summerInternships1.jpg"
+---
+
+I'm Bledea Bogdan and together with Patricia Atieyeh, both second year students at Polytechnic University of Timisoara, we built a feedback box app for Haufe-Lexware.
+
+Today is the last day spent @Haufe. And I must admit, this summer internship was simply awesome. My work colleagues were so friendly, they helped me when I was in trouble. And I didn't thought it's so fun to go to work.
+
+Below, is a screenshot of the application we built during this intership, built with the Meteor framework. Meteor is a brand new framework, both front-end and back-end, which makes Meteor a great framework.
+
+![Screenshot of the app](/images/summerInternships2.jpg){:style="margin:auto"}
+
+This application is for internal company use and it takes a feedback from a user, post it on the site, and sort the feedbacks by the number of votes. Users can  delete only their feedbacks, and the feedback can be modified only if there is no reply or vote.
+
+The development process was a little bit tricky for us, and, furthermore, it was the first time we used Meteor to develop web apps. But, in the end, we proved that nothing is impossible, and if you truly want, you can learn new things anytime.
+
+As you can see, this feedback box app has an user login&registration form, but, we restricted the account creation to the company email domain, haufe-lexware.com. After the user logs in, he can post and reply to the other feedbacks.
+
+And when I say it was tricky, I mean, the support on the internet for docker and meteor was so poor. I've had a lot of bugs, the meteor pack for docker it wasn't at least official, and the problems we encountered, was already posted on the internet, with a lot of troubleshooting, but, nothing for our case.
+=======
 ---
 layout: post
 title: Summer Internship @Haufe
@@ -25,3 +53,4 @@ The development process was a little bit tricky for us, and, furthermore, it was
 As you can see, this feedback box app has an user login&registration form, but, we restricted the account creation to the company email domain, haufe-lexware.com. After the user logs in, he can post and reply to the other feedbacks.
 
 And when I say it was tricky, I mean, the support on the internet for docker and meteor was so poor. I've had a lot of bugs, the meteor pack for docker it wasn't at least official, and the problems we encountered, was already posted on the internet, with a lot of troubleshooting, but, nothing for our case.
+>>>>>>> haufe/master

_posts/2016-10-07-HackathonInsights.md

@@ -0,0 +1,79 @@
+---
+layout: post
+title: Project: B#1 
+subtitle: Insights from the Freiburg Hackathon: New online Queue Management in Bürgeramt
+category: product
+tags: [Mobile, Open Source]
+author: daniel_wehrle, anja_kienzler
+author_email: daniel.wehrle@haufe-lexware.com, anja.kienzler@haufe-lexware.com
+header-img: "images/FR-hackathon-2016/2016_09_08_11_22_05_Hackathon_2016.png"
+---
+
+A Hackathon is a kind of software prototype development marathon. This year the second Freiburg hackathon took place. The target was to develop an application for “Newcomers” to the city of Freiburg in 48 hours (Friday evening to Sunday morning). We accepted this challenge with the idea to create less-stressful way to manage the necessary administrative procedures at “Burgeramt Freiburg” (city government administrative services) for foreigners and employees alike with the possibility to extend the system to other official city departments at a later point.
+
+### The technologies
+
+Among newcomers, smartphones are more common than personal computers, and we decided to build an smartphone app instead of a website because the solution required personal user settings and an offline mode function which we shall address below. The project goals we defined were:
+
+1. An online function for receiving a number (ticket) for a queue at one of the city offices. The application should also provide users with information about current waiting times so they are on time for their appointments. If you use this app, you should feel like you are the first in line upon your arrival. 
+2. Retrieval of digital forms in various languages, including a checklist of the required documents and forms needed for “Bürgeramt” appointments. This ensures that you do not have to come a second time because you forgot something. This feature also includes a database of translated forms that are normally only available in German. Even if they have to fill out the German forms, newcomers may see the questions in a language they are familiar with.
+3. An App-UX that is easy to understand and comfortable to use even if the user is not always online.
+
+Due to the short timeframe, our team had to make use of one technology that was known by the whole team, and so we also decided at very the beginning to develop in C#.
+
+As platform options, we had Xamarin and Universal App and we decided to use Universal App because the team was also more familiar with this technology. 
+
+### Technical doing
+
+The project was then split into the subprojects UX-concept, Data Layer, Office and Queue Management, QRCode Scanning, and Document Storage. One developer was responsible for one subproject. Several times during the Hackathon, developers switched subprojects. 
+
+### UX-concept
+
+Working on the UX-concept and on the interface design started some days before the Hackathon. This allowed us to complete our UX-concept shortly after the event started so the developers could get the most out of the short timeframe of the hackathon.
+
+The aim of the UX-concept was to make an interface that is easy to understand - the exact opposite of German bureaucracy. The user should always be guided to the best action, moving through the application in a few simple steps and reaching the desired goal quickly and easily.
+
+To achieve the UX-concept, it was important to start from the user's point of view by reorganizing and resquencing the existing appointment categories of the “Bürgeramt” to meet newcomer needs.
+
+The design is friendly and welcoming and supports easy navigation by using flat buttons and a clear menu prompt.  Because of the app’s name, B#1, and the characteristic behavior (diligent and useful) the mascot is a friendly bee.
+
+### Data layer
+
+While the design was being finalized, the developers started on the data layer. This subproject is the major backend component, and the data layer holds all user data, offices, lines, advices (representations of Bürgeramt appointments) and requirements - like required documents - for these advices. Because advices are built in a tree structure we built in a self-reference from advice to advice.
+
+![Hackathon class model]({{ site.url }}/images/FR-hackathon-2016/2017-09-09_HackathonClassDiagram.png){:style="margin:auto"}
+
+A simple XML solution for the data, stored directly on the phone, was our first choice to get the version of this main component running quickly. This was important so other developers could start using data for our app very early. 
+
+The next step was to connect via WebService to a server and to update this data. The information should always stay on the phone to enable offline browsing of the data. Only the functions of receiving a line number, checking current waiting information and downloading documents should require an internet connection. This was clearly defined because newcomers often are dependent on Wi-Fi which is generally not available. 
+
+The offices’ addresses and required data were taken from the city of Freiburg homepage. For the demonstration, we implemented a test data generator to create the rest of the data (number of people currently waiting, next number in line and so on).
+
+### Queue management
+
+For each possible type of appointment, we set a fixed waiting time, in a later version, we will improve this by adding self-learning. For each office, we defined one FIFO (First in, First out) queue filled with waiting tickets. 
+
+By using the queue information, it was possible to calculate the current waiting time and the next ticket number. 
+
+#### QRCode scanning
+
+To realize this function, we included the XZing.Net component Nuget package. The usage was very straightforward, the only thing that was a little bit tricky was to improve focusing of the phone camera. But in the end we figured it out. 
+
+In the QRCodes, we embedded the IDs that are associated with links to specific documents stored in our data layer. So for "advice requirements", we were able to use the same ID and link for QR Codes and associated documents and to avoid storing duplicate data.
+
+The ID made it possible to change the storage locations for documents without needng to reprint the QR Codes.
+
+### Document storage
+
+Document storage was a nice to have feature which is why we started working on it last. We settled for a very quick solution. We only stored IDs (Used for QRCodes) along with http links to the documents so we could use cloud storage to address the documents.
+
+Because we did not know at that point whether a centralized or an individual storage from the independent office should be used, the document storage solution functions with both local storage and remote storage.
+
+### Conclusion
+
+Getting a project done in two days is not an easy task. It requires great effort and teamwork. Building a team consisting of members from different Haufe Group departments is also not easy - especially considering that each member is busy with his/her own projects.
+
+In the end, we completed the project and it was possible to produce a prototype within 48 hours. For this kind of a project, our takeaway is that you have to concentrate on the core functions and use as much external code as possible (Nuget, OpenSource Libraries etc.). Another takeaway was that it is good to have a finished design concept at the beginning of the project. The completed UX-concept helped guide our coding.
+
+Freiburg Hackathon was a good challenge to learn new things and test our skills in a “new project environment”. We all liked the concept of the hackathon.
+Finally, we believe our idea is a good concept that will be a really nice, working product. Because of the short timeframe there is still a lot of work to do, turning many of the functions, that are right now “dummies”, into full-fledged features. 

_posts/2016-10-11_WindowsHello-2FactorAuth.md

@@ -0,0 +1,48 @@
+---
+layout: post
+title: Two factor authentication with Windows Hello and Google Authenticator 
+subtitle: Exploring new ways to make customer login more secure
+category: howto, product
+tags: [Security, Mobile, Open Source, API]
+author: daniel_wehrle
+author_email: daniel.wehrle@haufe-lexware.com
+header-img: "images\bg-post.old.jpg"
+---
+
+Currently all of our Lexware “on-premise” products work, using the well-known user/password login authentication. But, in the last couple of years, new techniques for authentication have become available, and we tested some of these technologies - Windows Hello and Google Athtenticator - to make proposals for alternative authentication and authorization technologies for Lexware products - especially for our “on premise” products.
+
+### Windows Hello
+
+“Windows Hello” has been available since the release of Windows 10 and is integrated into Microsoft’s sign-on service “Microsoft Passport”. Windows uses this service to enable login by face recognition or by other biometric methods, like fingerprint recognition. The face recognition requires a special camera (“Intel RealSense”), consisting of two cameras for visible light (for 3D scanning), and one infrared camera, to ensure the face recognition is not run on a photograph. These cameras are not widely distributed across the laptop market.
+
+I started to check and go through the information Microsoft provides for integrating “Passport” and “Hello” into applications.
+
+I also started recoding the sample from the pages, creating a simple Universal Windows Platform (UWP) app that performed indentification by Face recognition - [See Sample on MSDN](https://msdn.microsoft.com/en-us/windows/uwp/security/microsoft-passport-login-auth-service). The sample was short and pretty straightforward. It contains a simple xml serialization framework that would need to be replaced by a more secure data layer for productive usage. But to get started it was a really good resource.
+
+The next step I had planned was to transfer this sample from UWP into a normal desktop app. Here I was confronted with a show stopper: The Microsoft Passport and Windows Hello components were located in the WinRT Framework, but I planned to use the .Net Framework. I found a lot of information how to use WinRT Components in normal .Net applications - [e.g. on CodeProject](http://www.codeproject.com/Articles/457335/How-to-call-WinRT-APIs-from-NET-desktop-apps). There is also a [compatibility list](https://msdn.microsoft.com/en-us/library/windows/desktop/dn554295(v=vs.85).aspx), but Microsoft Passport and Windows Hello is not part of it, so there is no guarantee that it will work. After I finished the import I was faced with fact that it was impossible to initialize the Passport framework. 
+
+We verified this by asking our Microsoft contact, who gave us the same information: Hello was only supported for UWP, not for old style Windows applications.
+
+After learning that not all WinRT features can be used in the .Net Framework we had to put the project on hold.
+
+### Google Authenticator
+
+Now we had go back and rethink about how this project was defined, the main goal was a more secure authentication. So we checked for other possibilities and remembered that there was a time limited token system from Google. 
+
+Time limited tokes are also known as TOTP (Time-Based One-Time Password Algorithm see RFC 6238). Those systems generate passwords that are only valid for a limited time, those passwords are also called tokens. Normally the generation of a token is limited to one hardware device. In the past, token generators were a small piece of hardware including an LCD display, showing the current token. Google Authenticator does not rely on dedicated hardware and makes it possible to turn every smartphone into a security token generator.
+
+So I began to research how to use Google Authenticator with .Net. I found out that there are open source .Net Projects on [GitHub](https://github.com/brandonpotter/GoogleAuthenticator). I integrated those to my failed port of the Windows Hello app and was happily up and running with very low effort.
+
+It was clear that biometric authentication can definitely make authentication more secure, and so I did a little more research on recommendations for secure authentication. 
+
+### Takeaways for moving forward with two factor authentication technologies
+
+Two factor authentication can indeed bring a lot more security to applications. Data thieves not only have to get the password but also the token or biometrical information. And this information cannot be replicated as easily as a password.  
+
+But the technology that holds the second factor must also be secure itself. Windows Hello and Google Authenticator seem to be secure technologies. So it makes sense to use them as a second factor for higher-priority security issues. And, it also makes sense to use these technologies to build an up-to-date, secure authorization service. In any case two factor authorization should be adopted. Both technologies are easy to use, both for integrating into a software, and also from the customer-use standpoint. Like this, the security of an authorization process can be tightened with just some simple steps. 
+
+It’s too bad that Windows Hello does not work for classic desktop apps. Another drawback is that the availability of hardware (cameras) may limit the number of possible users. But, with Google Authenticator, there is an available technology that can be used on most smartphones and with all kinds of applications.
+
+Two factor authentication may not be a requirement for each simple login. But at administrator login or for a task with a higher security risk, it makes much sense to perform a second authentication step, at least as an option for the user. This does not require more effort or extra steps from the users but does heighten the security for critical operations. 
+
+Since it only requires low effort to integrate and use, I would recommend this technology to every developer, to enhance security for their applications and make use of Windows Hello or Google Authenticator, and I am also proposing two factor authentication to our product management because it would definitely be a product-feature quick win for us and our customers.