1 / 43

Passwords – Single Sign-on Keyring

Passwords – Single Sign-on Keyring. Group B125. Presentation. The goal of this project and presentation Presentation overhead: Problem analysis General security Design Implementation Demonstration Reflection Process Analysis. Problem analysis.

felix
Download Presentation

Passwords – Single Sign-on Keyring

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Passwords – Single Sign-on Keyring Group B125

  2. Presentation • The goal of thisproject and presentation • Presentation overhead: • Problem analysis • General security • Design • Implementation • Demonstration • Reflection • Process Analysis

  3. Problem analysis

  4. Introduction To Problem Analysis • Many different services requires many logins • Leads to poor passwords or forgetting passwords • Creating a secure single sign-on solution

  5. Initiating Problem • The initiating problem of the project: • ”The single sign-on solutions availabletodayareinsecure and/or troublesome to use. There is a need for an easy to use, secure single sign-on solution.” - Section 1.2, Initiating Problem

  6. Single Sign-on • Single Sign-on centralizes the login-procedure NemID- a single sign-on solution • Requires 3 items: • Personal ID • Password • Key from keycard

  7. Passwords • Passwords • Easy to remember, hard to guess • Obvious passwords • Lots of tips and advice on creating good passwords

  8. Stakeholders A stakeholder is: • A person with interest in the project • Examples of our stakeholders: • The buying company (e. g. Spar Nord) • The user of the login-system • Costumers of the buying company

  9. The Buyer • Interested in: • - Easy maintenance and updating • - High usability • - High security • - High quality software

  10. The User • Interested in: • - Easy to use • - Efficiency • - Security

  11. Security

  12. Account and computer safety • Login credentials • A lot of options for hackers

  13. ProtectionAgainst Hacking: • Keepingsoftware up-to-date • Encryption • Protection against SQL Injection

  14. Client/Server Theory: 4 Layers: • Data capture • Business rule • Application interface • Application server

  15. Internet Protocol Suite 4 Layers: • Link • Internet • Transport • Application

  16. Secure Sockets Layer • Encryption • Handshake • Certificates

  17. Virtual Local AreaNetwork • Local Area Networks • "Looks" like a LAN to the computers • Security by segmenting LAN networks

  18. Virtual private networks

  19. Design

  20. Design – Initial thoughts • Basic functionalityavailable to the user • Making the solution secure as possible • The administration shouldbe ”light” for system admins • Shouldbeable to handle anynumber of different services

  21. Design – Basic User Functionality

  22. Design – SecuringThe Solution • Company bestpracticeshelpsa lotto preventintrusion Whatwewant: • Encrypt passwords and hash keyswhenstored in database. • Encrypt data transmittedbetween the Server and Client application • Use a 3-way authentication system – with hardware as one of the authentication factors

  23. Technical Requirements • Database integration for increasedflexibility and speed • Encryption/ decryptionfunctionality • SSL connectionbetweenclient and server • USB drive recognition • Websocketas maincommunicationtoolbetween 3rd party plugins

  24. System Level Diagram

  25. Flowchart

  26. implementation

  27. Server Documentation ListenForClients() • Runs on its own thread • Creates instance of TcpListener • Sets up asyncronouscallback • Listens while server is running • Uses manual reset

  28. Server Documentation SQLDBQuery constructor • Prevents SQL injection • Same syntax as string.Format • Uses MySqlHelper

  29. Client Documentation GetStream() • Creates SSL stream to server • Creates TcpClient • Closes insecure stream • Returns secure stream

  30. Client Documentation RawToWebsocketClient() • Converts plaintext response to byte-array • Makes sure it's compliant with the websocket protocol

  31. Client Documentation Locating websocket package • Stores incoming messages in byte-arrays • Searches for start and end bytes • Retrieves messages between start and end bytes

  32. AKP Keyring Protocol Documentation Escape() • Escapes special characters used by our protocol • Checks each byte in a given array • Uses reference parameter

  33. Demonstration

  34. Demonstration Parts Chrome Client Overview: • The client application • The Chrome extension  Task: • Log in to a service • Let the application store the credentials • Log out from the service • Log in again by using the application to retrieve the credentials.

  35. Reflection

  36. Program flaws and lacking features • Program freezes on login • Solution: threading! • Database encryption • New feature: Change password from the client • New feature: Blacklisting save-password function on unwanted services • New feature: Password deletion on chosen pages (server part is alreadycompleted)

  37. Future perspective Estimatedcost of developing the product: • 4/5 peopleworking on the program (estimatedduration, 6 months) • Office rental Expanding the product: • The program MUST maintainsimplicity • The program willlosesimplicity by expanding it further Scalability: • The program must bescalable to beuseful • Must be an important part of future planning

  38. Conclusion • Because of licensingimplementing the software is the only form of income • All subquestions in the reportwereanswered • Succesfullydeveloped a program to store and retrieve password / username for any webservice

  39. Process analysis

  40. Description • Project Planning • Group Work •  Group roles • The role of the secretary at meetings rotates • Project leader: Christoffer • Lead programmer: Jeppe •  Weekly Schedule • Work hours: 09:00 - 16:00, although exceptions are allowed if people work extra • Break: Lunch at 12:00, approximately 45 minutes • Deadline for worksheets: Monday • Proof-reading every Friday at scheduled meeting • Cooperation with Supervisors

  41. Evaluation • Project Planning • Group Work •  Cooperation with Supervisors

  42. Analysis • Project Planning • Group Work • Cooperation with Supervisors

  43. Synthesis • Work for the next project • Things to keep for the next project

More Related