Some protocols used by banks - ie: SSL/TLS are currently deployed in the existing model, however the authentication is somewhat moot as there's not real steps taken to validate the user is indeed the autherised user and the cookie used as an authentication token is left everywhere the user doens't specifically remove it from, and doesn't seem to expire. It's also apparently vulnerable to some MITM evilness which will result is plaintext transmission of it. And likely a lot more because you take security "seriously".
TBH, "layman" and "lead admin" are a little contradictory. Silghtly. Security should be something of initmate familiarity to admin.
IMHO about as secure as "login" can be made would be use of PKCS-11, there's a reason most .gov and DoD and many lower organisations that are actually serious use this. However, about as secure and far more accessible to most users can be X.509 - Which is related to SSL/TLS - this is common technology, throughly tested and users should be able to trivially generate themselves a pair of certificates. They can then have the keys signed by the server's CA allowing it's use for login without ever having to transmit the key. Keeping it as secure as they can keep the key, and the passphrase they should set with it's generation. This passphrase should prevent unautherised use, and the certificate is next to impossible to either guess or brute force.
X.509 and use of is not a complex topic, and for the people really scared of using their computer it should be possible to script up something that will generate them certificates uniquely from a single click, and some minimal data input. It should even be possible to have the site generate them, but it's more secure if the private key never leaves the user's possession. Then it's impossible(or thereabouts) for anyone else to login using that auth.
Mobile banking apps are not overly brilliant models. Commonly, I would indeed suggest banks as security models to emulate as they do tend to have a clue here, but mobile banking solutions are commonly rendered insecure by unsafe implimentation of TLS or implimentaiton of known insecure protocols like SSL, The things they are starting to accept as forms of ID - like voice - are quite laughable. You don't want to use things that are left everywhere - like fingerprints, and voiceprints - as forms of ID. There's already open source projects for both(text to speech engine for the voice auth and 2D and 3D printing solutions for fingerprints, facial recognition is even easier to spoof). Almost everything being rolled out about now has three to five independant ways to spoof.
To be honest, most breaches of credit cards etc are at the Point of Sale or thereabouts. People putting their cards into skimmers inserted into cash machines, or point of sale devices, skimmed by store employee, skimmed by passer by with RFID booster sweeping CC details from a 30ft radius as they walk down the street - the website you used the CC with kept a copy of the details then secured it like this site and lost a copy of the database, sat on public wifi someone else redirects your traffic to sample...
Next up in frequency is insecure devices and networks used to access the services. It's amazing what malware people will install on their devices. Or the things attached to emails downloaded and allowed to execute. I've seen pretending to be legitimate banking apps, intercepting data from the legitimate app and pushing network traffic through a third party to sample the transactions(including authentication details). This is going to be the most difficult thing to secure this from.
For "social media" functionality, the likes of the suggested previously(or elsewhere) GNUSocial and Diaspora should roll out similar funcitonality to FB & twitter. If we had some sort of portal, integration into this into existing services should be simple as it's all open source, and long term maintainence should be taken care of by those projects themselves, allowing to reap the benefits of developing in a modular fashion. Something like XMPP could give off a full comms protocol stack. If combined with something like kamailio then it could even go VOIP/SIP with ease. Access to collaborational tools will enable fluid productivity across a wide range of topics.
By concentrating the same devel effort you would for a "mobile app" on the content this site delivers to mobile devices you could end up saving yourself at least three times the effort to do the same thing(website, IOS, Android devel vs website).