Do virtual keyboards promote weak passwords?

I’m quite big on password complexity. I like to use mixed case, numbers and special characters in my passwords.

Since having the iPad (and now the Android phone) I find it a real bind typing in strong passwords. The mixed case isn’t so bad, but I do have more login mistakes with the virtual keyboard. What really bugs me is having to switch keyboards two or three times to get all the special characters and numbers in. Every time I have to type a password on a mobile device I feel a certain tension…

My recent experience has left me thinking how nice it would be to have a weak password, preferably lower case letters only. So my next thought was, do virtual keyboards promote weak passwords?

Of course, I don’t expect anyone to comment and admit they have switched back to weak passwords, but it would be nice to know if anyone else feels my pain… 🙂

Cheers

Tim…

SecureFiles in Oracle 11g…

I’ve just posted an article on SecureFiles in Oracle 11g. It looks like Oracle have done a pretty good job of improving LOBs in 11g. Depending on the LOB contents, and provided you can cope with the processing overhead, you can certainly save some serious space using the compression and deduplication options. Anyone who’s used Transparent Data Encryption (TDE) will recognize the encryption options.

I can’t see the old-style (BasicFile) LOBs lasting very long now this is in place. 🙂

Cheers

Tim…

Lots of good stuff out there…

There’s some good stuff out on the net today:

  • Tom is back and talking about the level of skills in the IT industry. I think we all share his pain. 🙂
  • Mary Ann Davidson has a great piece on security. This links in nicely with what Tom was saying, in so far as it relates to skills with the IT industry, albeit from a security standpoint.
  • Continuing the security theme, Pete Finnigan made some comments on my recent article on fine grained network access controls. I still get a kick out of being mentioned by famous bloggers, even if it is an attempt to keep me on the straight and narrow. Thanks for the heads-up Pete. 🙂
  • Jake from Oracle AppsLab has a piece on the move back to the desktop. I find myself having conversations on this subject so often these days.
  • Finally, David Aldridge is trying to add fuel to a fire. 🙂

Sorry to everyone I didn’t mention. 🙂

Cheers

Tim…

Fine-Grained Access to Network Services in 11g…

Continuing my OCP 11g upgrade campaign, I’ve been looking at Fine-Grained Access to Network Services in Oracle Database 11g Release 1.

This represents a pretty major security improvement for Oracle 11g. In previous versions the all-or-nothing security associated with database callouts was a little ham-fisted to say the least.

On the down side, I think it will confuse a few people when they are upgrading existing databases, but it’s a small price to pay for the peace of mind.

Cheers

Tim…

Schema Owners and Application Users…

I was trying to explain to a colleague the concept of using application users, rather than logging directly into the schema owner. Although it’s a very basic point, it seemed worthy of a write-up, especially because it’s been a long time since I’ve written anything about Oracle. So here is it:

Schema Owners and Application Users

Cheers

Tim…

Is read-only access to production systems safe?

There is an interesting thread on the Dizwell Forum about access to production systems using tools like TOAD. Of course, this begs the question, is there such a thing as “safe” read-only access to production data?

If you are allowing read-only access to tables on a production system, you are also allowing record and table locking. If you don’t believe me, take a look at this:

tim_hall@dev1> CONN sys/????@db10g AS SYSDBA
Connected.
sys@db10g> CREATE USER test_user1 IDENTIFIED BY test_user1 QUOTA UNLIMITED ON USERS;

User created.

sys@db10g> GRANT CONNECT, CREATE TABLE TO test_user1;

Grant succeeded.

sys@db10g> CREATE USER test_user2 IDENTIFIED BY test_user2 QUOTA UNLIMITED ON USERS;

User created.

sys@db10g> GRANT CONNECT TO test_user2;

Grant succeeded.

sys@db10g> CONN test_user1/test_user1@db10g
Connected.
test_user1@db10g> CREATE TABLE test_tab1 (
2    id  NUMBER
3  );

Table created.

test_user1@db10g> INSERT INTO test_tab1 (id) VALUES (1);

1 row created.

test_user1@db10g> GRANT SELECT ON test_tab1 TO test_user2;

Grant succeeded.

test_user1@db10g> CONN test_user2/test_user2@db10g
Connected.
test_user2@db10g> DECLARE
2    l_id  test_user1.test_tab1.id%TYPE;
3  BEGIN
4    SELECT id
5    INTO   l_id
6    FROM   test_user1.test_tab1
7    WHERE  id = 1
8    FOR UPDATE;
9
10    ROLLBACK;
11  END;
12  /

PL/SQL procedure successfully completed.

test_user2@db10g> LOCK TABLE test_user1.test_tab1 IN EXCLUSIVE MODE;

Table(s) Locked.

test_user2@db10g> ROLLBACK;

Rollback complete.

test_user2@db10g>

Looks like the SELECT privilege is not so safe after all 🙁

Of course, you don’t need direct access to the tables. You could always provide access to the data via APIs, but that’s not what your average TOAD user wants to hear!

Cheers

Tim…