Stress på arbetsplatsen relaterat till många inkommande och utgående kommunikationskanaler är ett reellt problem. Applikationer som samlar alla kanaler i samma verktyg kan hjälpa till på det här området. För att förenkla vid utveckling av en sådan applikation kan ett modulärt system skapas, där varje modul ser liknande ut och enkelt kan kopplas in i en huvudapplikation. Den här studien undersöker de problem som kan uppstå när flera tjänster ska integreras, mer specifikt genom att titta på hur en befintlig modul för e-post via Google Apps kan porteras för att stödja e-post via Microsoft Office 365. Arbetet har skett enligt metoder för testdriven portering och varje steg i porteringen har dokumenterats noggrant. Ett antal problemområden har identifierats och möjliga lösningar föreslås. Utfrån de problem som uppstått dras slutsatsen att de är av en sådan karaktär att de inte utgör något hinder för en portering.

Modern users carry mobile devices with them at nearly all times, and this likely has contributed to the rapid growth of private user data—such as emails, photos, and more—stored online in the cloud. Unfortunately, the security of many cloud services for user data is lacking, and the vast amount of user data stored in the cloud is an attractive target for adversaries. Even a single compromise of a user’s account yields all its data to attackers. A breach of an unencrypted email account gives the attacker full access to years, even decades, of emails. Ideally, users would encrypt their data to prevent this. However, encrypting data at rest has long been considered too difficult for users, even technical ones, mainly due to the confusing nature of managing cryptographic keys. My thesis is that strong security can be made easy to use through client-side encryption using self-generated per-device cryptographic keys, such that user data in cloud services is well protected, encryption is transparent and largely unnoticeable to users even on multiple devices, and encryption can be used with existing services without any server-side modifications. This dissertation introduces a new paradigm for usable cryptographic key management, Per-Device Keys (PDK), and explores how self-generated keys unique to every device can enable new client-side encryption schemes that are compatible with existing online services yet are transparent to users. PDK’s design based on self-generated keys allows them to stay on each device and never leave them. Management of these self-generated keys can be shown to users as a device management abstraction which looks like pairing devices with each other, and not any form of cryptographic key management. I design, implement, and evaluate three client-side encryption schemes supported by PDK, with a focus on designing around usability to bring transparent encryption to users. First, I introduce Easy Email Encryption (E3), a secure email solution that is easy to use. Usersstruggle with using end-to-end encrypted email, such as PGP and S/MIME, because it requires users to understand cryptographic key exchanges to send encrypted emails. E3 eliminates this key exchange by focusing on storing encrypting emails instead of sending them. E3 transparently encrypts emails on receipt, ensuring that all emails received before a compromise are protected from attack, and relies on widely-used TLS connections to protect in-flight emails. Emails are encrypted using self-generated keys, which are completely hidden from the user and do not need to be exchanged with other users, alleviating the burden of users having to know how to use and manage them. E3 encrypts on the client, making it easy to deploy because it requires no server or protocol changes and is compatible with any existing email service. Experimental results show that E3 is compatible with existing IMAP email services, including Gmail and Yahoo!, and has good performance for common email operations. Results of a user study show that E3 provides much stronger security guarantees than current practice yet is much easier to use than end-to-end encrypted email such as PGP. Second, I introduce Easy Secure Photos (ESP), an easy-to-use system that enables photos tobe encrypted and stored using existing cloud photo services. Users cannot store encrypted photos in services like Google Photos because these services only allow users to upload valid images such as JPEG images, but typical encryption methods do not retain image file formats for the encrypted versions and are not compatible with image processing such as image compression. ESP introduces a new image encryption technique that outputs valid encrypted JPEG files which are accepted by cloud photo services, and are robust against compression. The photos are encrypted using self-generated keys before being uploaded to cloud photo services, and are decrypted when downloaded to users’ devices. Similar to E3, ESP hides all the details of encryption/decryption and key management from the user. Since all crypto operations happen in the user’s photo app, ESP requires no changes to existing cloud photo services, making it easy to deploy. Experimental results and user studies show that ESP encryption is robust against attack techniques, exhibits acceptable performance overheads, and is simple for users to set up and use. Third, I introduce Easy Device-based Passwords (EDP), a password manager with improvedsecurity guarantees over existing ones while maintaining their familiar usage models. To encrypt and decrypt user passwords, existing password managers rely on weak, human-generated master passwords which are easy to use but easily broken. EDP introduces a new approach using self-generated keys to encrypt passwords, and an easy-to-use pairing mechanism to allow users to access passwords across multiple devices. Keys are not exposed to users and users do not need to know anything about key management. EDP is the first password manager that secures passwords even with untrusted servers, protecting against server break-ins and password database leaks. Experimental results and a user study show that EDP ensures password security with untrusted servers and infrastructure, has comparable performance to existing password managers, and is considered usable by users.

No description available.

Tekniker för att hämta e-post har sedan länge varit svåra att hantera på grund av brist på en tydlig standard. E-post kan variera i vilka headers som följer med och vilken storlek som är tillåten. De kan även vara skillnader på hur mailet är kodat vilket kan bidra till att mailet inte lyckas parsas på rätt sätt. Äldre tekniker som IMAP4 och POP3 förlitar sig på en bristande autentiseringsprocess som inte är önskvärd. Projektet kommer därför studera de nyare teknikerna Outlook Mail REST API och Gmail API för att jämföra dem mot IMAP4. Syftet är att på ett säkrare och effektivare sätt kunna läsa epost och integrera dem med ett ärendehanteringssystem. e-postöverföringar ska kunna schemaläggas med specifikationer som sparas i en konfigurationsfil. För att uppnå syftet implementerades tre prototyper som använde varsin teknik för att läsa e-post. För att jämföra teknikerna på prestanda gjordes tidsmätningar. En jämförelse på säkerhet genomfördes genom att sätta upp den information som måste sparas i konfigurationsfilen. En jämförelse på funktionalitet genomfördes genom att jämföra en lista på funktioner som bestämdes genom en intervju och därefter se om dem finns på de tre olika teknikerna. Resultatet blev att Outlook Mail API var överlägset bäst när det kommer till prestanda. Den stora anledningen varför var att Outlook API hämtar e-post i plain-text vilket leder till en betydligt kortare tid för att parsa e-post. Gmail API var snabbare än IMAP4 mest troligt för att den använder protokollet http för att hämta epost. Både IMAP4 och Gmail API hämtar e-post i form av MIME-meddelanden vilket ledde till en ungefärligt lika lång tid för parsning. Funktionaliteten för teknikerna var densamma förutom några få skillnader. Outlook API har funktionalitet för att hämta epost i plain-text medan de andra inte har det. Gmail API har inte möjlighet att sortera inkommande e-post. Slutligen kom projektet fram till att Gmail API och Outlook Mail REST API var säkrare än IMAP4 på grund av den modernare autentiseringsprocessen som inte hanterar några lösenord. Både Outlook och Gmail använder Oauth2 som autentiseringsprotokoll. Utifrån resultatet dras slutsatsen att Outlook Mail REST API är den lämpligaste lösningen baserat på dess säkerhet och prestanda. / The process to fetch email has for a long time been a difficult task because of the amount of different standards in email formats. Email can vary in different headers, format, max size and more based on which email supplier sends the mail. Older methods for fetching email as IMAP4 and POP3 still relies upon weak authentication processes. This project will therefore study the new technologies Gmail API and Outlook Mail REST API and compare these to IMAP4. The purpose of this study is to find a more effective and secure way of transferring emails from an email server to the system named Easit GO. Email transfers should be able to be scheduled in such a way that it is specified in a configuration file. To accomplish this three prototypes was implemented. Every prototype used on of the technologies to read email. To compare these prototypes there was a performance test through time measurements. To compare functionality there was a list setup of fixed functions showing which technologies that had support for that specific function. Security was based on the sensitive information that was stored in the configuration file. The result was that Outlook Mail REST API clearly beat the others on performance. This was because of outlooks ability of reading email in plain-text which leads to a substantially shorter parsing time. All of the technologies had similar functionality except for a few things. Outlook API had the possibility of reading email in plain-text which resulted in better performance. Gmail API did not have functionality to sort incoming email on oldest first. The study concluded that Outlook API and Gmail API were more secure than IMAP4 because of no passwords were saved or even used in the prototype. Both Outlook and Gmail used the authentication protocol Oauth2 which is more secure than IMAP4s Basic Authentication. The conclusion points to Outlook Mail REST API being the most suitable solution based on its performance and more modern authentication.

Datormoln, även kallat molnet, är teknik baserad på användande av applikationer och data över Internet. Molnet erbjuder olika typer av tjänster och resurser som t.ex. applikationer och datorkraft. Molntjänster kan underlätta för företag då de kan sänka den annars höga kostnaden för saker som personal, hårdvara, mjukvara och det utrymme detta kräver. Denna rapport kommer svara på frågan ”Vad är moln?” och grundläggande beskriva molnets struktur och funktion, samt olika typer av moln. Rapporten kommer även beskriva ett par olika molntjänster.