Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Cyber Security
Similar to Cyber Security (20)
Recently uploaded
Recently uploaded (20)
Cyber Security
- 1. Security Standards Authentication in practice Amit Bezalel / Israeli Site System Architect Change Healthcare
- 3. Encryption History -1500 – Encrypted clay tablets from Mesopotamia containing trade secrets - 650 – Spartans used Scytale transposition - 600 – Hebrew scholars use Atbash ciphers - 400 – The Kama Sutra & Greek scripts use substitution ciphers +600 – Arab mathematicians document cryptography & statistic cipher cracking +800 – Encryption used and advanced in England +1400 – Arab scholars write about multiple-substitution ciphers +1460 – Polyalphabetic ciphers, first that are safe from statistic methods +1600 – Cryptography takes part in European political battles (Elizabteh I) +1840 – Edgar Allan Poe (writer) challenges people to send ciphers, solves all +1917 – World war I: British broke German naval codes, gaining action plans +1936 – World war II: Cipher machines (German Enigma) +1937 – British TypeX machines (lessons learnt from enigma) +1990 – Internet Age, DES (Data Enc Standard) 56bit cipher +1995 – SSL 2.0: First mainstream version of channel encryption +1996 – SSL 3.0: Longest lasting variant +1999 – TLS 1.0 +2001 – AES Encryption standard
- 4. Substitution cipher examples Main Idea: Substitute each letter for another: ● ROT13 ● אתבש ● Ceaser’s Cipher Notice: Char pairs always stay tied (A is always N)
- 5. Transposition Encryption examples Double Transposition Scytale cipher Main Idea: Shuffle letters around
- 6. Symmetric Key Encryption example Main Idea: Mix text chars with a secret key Input: “This string should be kept secret” Key: “mykey” This string should be kept secret mykeymykeymykeymykeymykeymykeymyk T+m => @ h+y => # i+k => % s+e => 6 +y => R s+m => X t+y => 8 T <= @-m h <= #-y i <= %-k s <= 6-e <= R-y s <= X-m t <= 8-y Encrypt: Decrypt:
- 7. Rotor machines Encryption (enigma) Main Idea: A complex circuit with moving parts that change each char Notice: • Same Letter in Text ≠ same in EncText • It’s basically a mechanical symmetric key [What is the key size?] Enigma movie Enigma’s flaw Combinations ≈ (159 x 10^18) 159 quintillion
- 8. Modern Encryption Two forms of encryption: ● Symmetric: same key for enc/dec ● Asymmetric: Two keys Key1 Key2 Key1 Key2 We hide one & call it “ ”
- 9. Hashing Hashing / Bit Printing ● Maps data to a fixed field of values ● Any size input -> Fixed size string SHA256 CA7E3F3F3391B 594650E7BA0FA 4787C90BCD4A3 ABE5224C50C1 D255A0A67A891XXX Infinite possible values
- 10. Hashing A good hash is: ● Hard to guess ● Spreads wide, so collisions are rare ● One bit change -> Whole string change Hash algs: Sha256 Sha1 (insecure since 2016) MD5 (insecure since 2005) MD4 (insecure since 1990)
- 11. Hashing Hash is used for: ● Storing User passwords ● Digital Signatures ● Unique identifiers for: files / commits / crypto blocks / etc..
- 12. Digital signatures Signing: ● Hash the document ● Encrypt hash by using the PrivateKey ● Attach to document and send: ####### ~#######~ ~#######~
- 13. Digital signatures Why not encrypt with PublicKey? ● Encryption is usually done with PublicKey ● Decrypted only by PrivateKey owner ● Here decryption is public --> encryption by owner is validated
- 14. Digital signatures Verify Signature: ● Hash the document ● Decrypt signature with PublicKey ● Key is received from the server ● Matching results = no tampering ####### ~#######~ ####### =
- 15. Certificates Publishing a PublicKey: ● Should be safe from counterfeits ● A known authority should sign it ● Certification authority trusted by OS ● Preinstalled CA root certificates ● A cert is Info + PK signed by CA
- 16. Channel Encryption Need: Encrypt internet conversations ● Asymmetric is more CPU heavy ● Client Keys are hard to install (many clients) Solution: ● Client encrypts with Server PublicKey ● Server decrypts with PrivateKey ● Agree on a random symmetric key ● Use symmetric key.
- 17. Channel Encryption history SSL 3.0 “Secure Socket Layer”: ● Released in 1996 ● Deprecated 2015 (“Poodle” Attack) ● Swapped out for TLS TLS “Transport Layer Security”: ● TLS 1.0 (1999), 1.1 (2006) should not be used (2020 deprecation) ● TLS 1.2 (2008) – Widespread, Still considered safe ● TLS 1.3 (Aug 2018) – Better performance & security
- 18. Authentication & Authorization ● Authentication – User Identification Who are you? ● Authorization – Assigning Permissions What Can you do?
- 19. Authentication & Authorization You absolutely have to use standards in this area ● OAuth2 – The standard method for authorization (permissions) ● OIDC – The standard for Authentication (Identity verification) ● JWT – JSON Web Token, used to keep login info ● HTTP Cookies – saved by the browser and sent only to the source domain
- 21. OIDC flows OIDC has 3 flows for Identifying the user: ● Implicit ● Authentication Code flow ● Hybrid – combines aspects of both
- 22. Browser [User Agent] The Auth Code flow Auth Service [Identity Provider] Web Server Role: [Trusted Client] Redirect Browser to IdP User / Password Authentication form Request HTML page Get Token BrowserSave Token
- 23. OAuth Grant types OAuth has several flows as well called grants ● Implicit grant ● Authorization code grant (Remember OIDC?) ● Client credentials grant (client/secret) ● Refresh token grant ● Resource owner credentials grant (user/password)
- 24. Machine to API interaction Uses OAuth2 Client credentials: 1. Client ID: Calling Machine has ClientID & Secret 2. JWT Assertion: Uses a signed JWT with the client ID in the body
- 25. Introduction to secrets Services connect to different facilities: ● Infrastructure (e.g. Database, LDAP) ● Cloud services ● 3rd parties
- 26. Managing secrets Secrets: ● Database credentials ● API keys (Client/secret) ● Certificates ● Passwords ● Encryption keys
- 27. Managing secrets Secrets should be: ● Kept encrypted & under permissions ● Transmitted over encrypted channels ● Replaced periodically ● Be obtainable by trusted components Secrets can be exposed when laying around, or passed from hand to hand
- 28. Managing secrets Secrets in on-premise Apps: ● Keep encrypted files with permissions ● Use OS vendors for user encryption (DPAPI)
- 29. Bonus: Enigma’s Flaw Monthly code page: [day] [rotors] [rotor settings] [10 substitution plugs] Enigma never codes a char to itself ● Naturally occurring repeats ● 6:00 Weather report = “Wetterbericht” ● Slide to find the location => Big Clue!
- 30. Bonus: Enigma’s Flaw The rest is trying out combinations
Editor's Notes
- Authentication and Authorization are different things, which are usually done together. First, a user has to be identified or Authenticated when he logs in to the system, after he is proved to be a known user, he can get some permissions or get Authorized to access system operations. Both processes need to be properly done so they are hard to hack, successfully attacking the Authentication usually results in user impersonation, while attacking the Authorization means elevation of permissions.
- When talking about security implementations, It is extremely important to follow standards, secure authentication involves cryptography, hash functions, padding ,salting, one time phrases & messy redirects. It is extremely easy to get wrong, and a single bug can lead to stolen credit card information. In short: no custom implementation will ever have the level of attack proofing that a standardized and certified implementation has. OAuth is a standard for authorization, it was only meant for securely assigning permissions to an already logged in user, but due to a lack of good standards for user authentication at the time, many developers started implementing authentication on top of OAuth by reusing the some of the same calls to also verify the user and then retrieve his ID. As we already established, custom code means trouble in this area and standard implementations were required. The resulting standard was Open ID Connect also called “OIDC”, which facilitates user authentication over OAuth2. These standards are used along with standard tokens and storage methods to create an secure end to end solution that keeps the system safe.
- Access Tokens are short lived entry tickets into the system, JWT, JSON Web Tokens, are tokens written in JSON which can be signed and encrypted, the are usually stored either in cookies or in the bearer header of the http request. JWT Tokens have 3 parts: the header, the claims and the signature. The header contains the definition of the token & encryption parameters, the claims contain all custom information about the user and his permissions, and the signature contains the signed hash that can be verified to prevent tampering. JWT is simple and works in all popular languages, it is the recommended token format today.
- OIDC Defines 3 flows: The Implicit flow is meant for situations where we have no application level services between the client and the identity provider service, as is the case in some JavaScript only application served from CDN or in some native clients, which request data from cloud APIs without a middle tier. We can call it the “Front channel flow”. In the Authentication code flow is the most secure and the most used flow, it is recommended for All clients including mobile and native, and is usually implemented by opening a browser to do the credential exchange. The Hybrid flow is similar to the authentication code flow, but it skips the code and directly sends back a token to the Service. It is much less used than the previous two.
- In The Implicit flow the browser opens the Identity service’s sign-in page where the user fills in his password, the form is submitted, and the response redirects the browser back to the site url which was provided in the call, with the user ID & access token embedded in the url. This flow is less secure than the other methods, and should only be used for basic user details. Additionally, It does not provide a refresh token, and the same process should be done again when token expires.
- In the Authentication code flow: the a browser which calls our UI service, is redirected to the identity provider service sign in page, where the password is given, it is then redirected back to our service with a code, which will be exchanged by the service for an access token that can be sent back to the browser for use in all following transactions. This flow has the benefits of authenticating our service with the identity service, and not having to expose the token to the browser by saving it in a secure cookie which is not exposed to the client side code.
- There are 5 OAuth grant types, OIDC is built on top of OAuth, and the first two OIDC flows clearly follow OAuth grants paths. Client credentials grant is used for machine to API interactions like automation, which we will discuss later, and Refresh token is used for token expiry. The “Resource owner credentials” is actually the common practice of sending the user/password directly from the client to an API and receiving a token, it is not supported by an OIDC flow, and is considered less secure since it implies trusting the native client to handle the password. Native clients are vulnerable to memory tampering or scripting attacks that can expose the password, while browsers have defenses in place to handle these risks. The guidelines say we should use the authentication code flow for all clients, by opening a browser to serve as the “user agent” and handle the initial authentication, at the end of the process our application will receive the access token by listening to a port which will be called by the browser. This guideline which can be counter intuitive at first, applies to mobile applications as well as desktop native apps. You should keep in mind that browser security and credential handling is a deeply researched subject and that there is a good reason for this recommendation.
- Some of the interactions with the system will not involve a user, so filling a password form is not practical.. These cases require a different type of credentials, called client credentials. For this kind of interaction there are two methods of authentication: Using Client ID means that a user which logged into the system will create a client/secret combo and authorize it to do some limited actions. These client/secret credentials will be saved in the machine that requires API access and used to create access tokens. The second way is using a JWT, with the Client ID in the claims section, and signing it with a certificate on the client side, this method requires that the identity service trusts the certificates installed on the client side.
- Services have a natural need to connect to other services, but since channels need to be secured and identity verified we need to handle a lot of keys and certificates and passwords. For some cloud services the problem can be avoided by assigning roles to the running machine or the specific container, others like different database services or 3rd party vendors, require some sort of password or key in order to log-in. Secure connections require a certificate for the server side at least, and signature validation requires a public key to be obtained.
- In short, a secret is any information that should be kept confidential for use by the system. And you will find them all around once you start building up your solution.
- Secrets have to be kept encrypted while at rest and while in transit, The should be cycled regularly, distributed only to verified system entities, and revoked when compromised.
- Traditional apps had few facilities for handling secrets properly, and made do with what the OS provided. Cloud apps are attacked often, so they have a bigger need to secure secrets, that is why better facilities were developed.